Agile Business Analysis - The Key to Effective Requirements on Agile Projects
1. 22/11/2011
Agile Business Analysis
The Key to Effective Requirements
on Agile Projects
Shane Hastie MIM, CSM
Debunking the Myths
In Agile projects we don‟t just sit
down and write code like free-
form poetry!
– James King
(c) Software Education, 2010 1
3. 22/11/2011
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Manifesto para Desenvolvimento Ágil de Software
Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda.
(c) Software Education, 2010 3
4. 22/11/2011
The Agile Lifecycle
Envision Speculate Close
5% 10% Explore 80% 5%
Uncertainty in the Project Goal
What our
SRS spec’d
Uncertainty in
Stakeholder
Courtesy Philippe Kruchten
Satisfaction Space
Source: W. Royce, IBM
The Right
Initial State Actual Path and
Solution
precision of artifacts
(c) Software Education, 2010 4
5. 22/11/2011
Inside an Iteration
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
Iteration Task Task Task Task Task Task Task Task Wrapup
Planning Work Work Work Work Work Work Work Work
Daily Daily Daily Daily Daily Daily Daily Daily Daily
Standup Standup Standup Standup Standup Standup Standup Standup Standup
Task Task Task Task Task Task Task Task Present/
Work Work Work Work Work Work Work Work Retrospect
Backlog
Iteration Backlog
As a xxx I want yyy so that zzz
Story 1 Story 1
Iteration Story 2
Story 2
Planning Story 3
Story 3
Story 4 Iteration Tasks
Story 5 Task 1
Story 6 Task 2
Story 7 Task 3
Story 8 Task 4
Story 9 Task 5
Task 6
Epic 1
Task 7
Task 8
Epic 2
Task 9
Uncompleted Story 3
Task 10
Epic 3
Agile Needs Analysis
The hardest part
of building any
software system
is determining
precisely what to
build
Frederick Brooks
(c) Software Education, 2010 5
6. 22/11/2011
But the
Perception
Worse
It should be
red or I want a
I like green. range of color
purple. options including
green, blue , and
purple
It shall be
green.
(c) Software Education, 2010 6
8. 22/11/2011
They Change!
Are Requirements
Obsolete?
(c) Software Education, 2010 8
9. 22/11/2011
Reducing Waste
Leave things
until the last
RESPONSIBLE
moment
Photo by Nick Wheeler
Progressive Elaboration
Vision
Personas & Goals
Epics
Stories
Acceptance Criteria
(c) Software Education, 2010 9
11. 22/11/2011
Example: User Profiles
(c) Software Education, 2010 11
12. 22/11/2011
Epics
• Elementary Business Process
• One person, one place, one time
• Could come from a process
map
• Someone doing something
• Enough to prioritise
• Fulfil to the Vision & Goals
(c) Software Education, 2010 12
13. 22/11/2011
User Stories
• User Stories
• Guidelines for success
• Just-in-time
• Three C‟s
– Card
– Conversation
– Confirmation
Common format:
“As a <role> I want <thing to be delivered> so that <reason for the need>”
From Epic to Stories
• Identify the key process
elements
• Each piece of CRUD
• Consider the UI components
• “Happy days” steps
• “When things go wrong” –
preventing bad things from
happening
(c) Software Education, 2010 13
14. 22/11/2011
How Do Your Stories Smell?
• The Value of Quality
• Performance
• Efficiency
• Reliability
• Functionality
• Useability
• Maintainability
(c) Software Education, 2010 14
15. 22/11/2011
Acceptance Criteria
• 3rd C – Confirmation of the story
• Just-in-time
• Progressively evolve during backlog
grooming and development
• Add details as needed
• Process flows
• Data structures
• UI mockups
• Technical notes
• Examples
• Whatever is needed . . .
• BDD Format
• <given> <when> <then>
• Test design criteria
Behaviour Driven Development
• Express needs as behaviour using scenarios
• Scenario: Upgrade with sufficient air miles available
Given a traveller has a valid reservation in economy class
and he has sufficient air miles available
and there is a seat available in business class
when he requests an upgrade
then the upgrade should be provided
and his air miles balance reduced
and the economy seat released
and the business class seat reserved
(c) Software Education, 2010 15
17. 22/11/2011
The Agile Analyst
Scrum Roles
Scrum Master
Product Owner
The Delivery Team
(c) Software Education, 2010 17
18. 22/11/2011
Product Owner
• Greater project engagement
and leadership
• Understands the business &
project vision
• Empowered decision maker
• Daily involvement
• Review the plan every iteration
• How competent and
committed?
Where is the BA?
Product Owner?
Scrum Master?
A Team Member?
(c) Software Education, 2010 18
19. 22/11/2011
Changing the Rules
Break down the walls
Need to be a facilitator
Open the communication channels
Keeper of the value context
Different Engagement Types
1. Traditional Requirements Gatherer
2. Surrogate Product Owner
3. Second in command (2IC)
4. Business Coach
5. Co-ordinator
6. Facilitator
7. Not required / Unemployed?
(c) Software Education, 2010 19
20. 22/11/2011
Agile Analysis Guidelines
• See The Whole
• Think as a Customer
• Analyse to Determine What is Valuable
• Get Real Using Examples
• Understand What is Doable
• Stimulate Collaboration & Continuous
Improvement
• Avoid Waste
(c) Software Education, 2010 20
21. 22/11/2011
Other Types .
Quality ..
Requirement Model
Constrained by
(NFR)
Elaborated by
Optionally
State
Architecture Diagram
Requirement
Class
Backlog Item Diagram
Realised by
Use Case
Epic Story
UML Model courtesy of Dean Leffingwell
Process Model – Who? What? When?
44
(c) Software Education, 2010 21
22. 22/11/2011
Entity Relationship Diagram – With What?
Decision Table – What? How?
Condition Statements Rules
Purchased Full Fare Ticket? Y Y Y Y N N N N
Received Upgrade in Last 6 Months? Y Y N N Y Y N N
Gold Status? Y N Y N Y N Y N
Action Options Action Entries
Free Upgrade X X X
Discounted Upgrade Offer X X
No Upgrade X X X
(c) Software Education, 2010 22
23. 22/11/2011
Decision Tree – What? How?
Ticket Type? Freq Flyer Last Upgrade?
Level? ACTIONS
<= 6
Months No Upgrade
Not
Gold
>6 Offer Discounted
Full Months Upgrade
Offer Fare
Gold
Upgrade? Free Upgrade
<= 6
Months Offer Discounted
Discounted Upgrade
Gold
>6 Free Upgrade
Months
Not
No Upgrade
Gold
State Transition Diagram –
What? How?
(c) Software Education, 2010 23
24. 22/11/2011
Use Cases – What? How?
USE CASE # 002 Amend Reservation
Goal in Context This use case allows a reservations operator to amend or cancel a
reservation in response to a caller request
Scope and Level Flight Reservations System
Primary Task
Preconditions The reservations system will be up and running, the Reservations Operator will have
logged into the system
Success End Reservation details amended or removed
Condition
Failed End No change to reservation details
Condition
Primary, Reservations Officer (RO)
Secondary Actors Caller
Trigger This use case begins when the RO receives a request to change an existing reservation
DESCRIPTION
Step Action
1 The RO selects the reservation to amend
(search criteria/mechanism TBD, possibly by reservation number, caller name, passenger
name, journey details . . .)
2 The system displays the reservation and journey details for all journeys not yet started
3 …
Are User Stories Simply
Degenerate Use Cases?
Upgrade
Seat
(c) Software Education, 2010 24
25. 22/11/2011
Use Cases Versus User Stories
Use Case User Story
Transactional Statement of Value
Scope is “user valued Scope is determined by what
transaction” can be implemented in one
iteration
Conceptual (Model) Descriptive
Requirement Requirements place holder
Know Your Context
Source: Philippe Kruchten
Octopus Model
(c) Software Education, 2010 25
26. 22/11/2011
Agile Extension to the BABOK™
• Available for Download
• We NEED Your Feedback
• http://www.iiba.org/imis15/IIBA_Website/Professional
_Development/Agile_Extension.aspx
BABOK™ V3.0
• Change Framework
• Multiple Perspectives
– „Motivation‟
– Portfolio
– Program/Project
– Specialisations
(c) Software Education, 2010 26
27. 22/11/2011
Any questions?
Contact me:
• Email shaneh@softed.com
• Web www.softed.com
• Blog http://blog.softed.com
• InfoQ articles http://www.infoq.com/author/Shane-Hastie
• Twitter @shanehastie
• Slides available from www.softed.com/resources
Options for Open Space
• Enterprise Analysis
• BABOK 3.0 Change
Framework
• Writing Good User
Stories
(c) Software Education, 2010 27