Embed Size (px)
DESCRIPTION
A common question asked by teams adopting agile is "what does business analysis look like in agile?" The common answer is "writing user stories". WRONG! Okay, maybe not wrong, but certainly not the whole story (pardon the pun). Business analysis in agile is concerned with understanding the problem and possible solutions in order to ensure the team is building the right thing. User stories can be helpful, but are certainly not sufficient for doing that. In this session, Kent McDonald describes how you can perform just enough business analysis to discover the right things to build. This includes how to really use value to decide what to build first, why process flows, data models, and mockups are still extremely helpful, and why the function of user stories is more important than their form. Along the way, Kent shares examples from a system replacement project he is working on and suggests ways you can apply these techniques to your own projects.
Citation preview
Analysis in Agile: It’s More Than Just User Stories
Kent J. McDonald@beyondreqs
What does business analysis look like in Agile?
Agile approaches describe delivery
Where does this come from?
And then a miracle occurs
Voila! A Backlog.
But there may be some problems…
Do you have a complete solution?
Is the backlog more like a wish list?
Use models and stories to
describe what to build
How to determine what is “just
enough”
Analysis in Agile
Use value to determine the right thing to
build
VALUE
INPUTS
INPUTS
PROCESS
Use value to determine the right
things to build
OUTPUTS
VALUE
An example would be handy right about now
Enterprise System Replacement
New System
Initial Approach to Analysis
New System
New Approach to Analysis
New System
Impact Mapping
© Gojko Adzic 2012For more information:
impactmapping.org
Goals
Why are we doing this?
© Gojko Adzic 2012
Actors
Who can produce the desired effect and who can obstruct it?
© Gojko Adzic 2012
Impacts
How should our actors behavior change?
© Gojko Adzic 2012
Deliverables
What can we do as a delivery team to support
the required impacts?
© Gojko Adzic 2012
© Gojko Adzic 2012
Validating assumptions
© Gojko Adzic 2012
Identifying user stories
© Gojko Adzic 2012
IMPACT
Story Mapping
Identified our personas
Identified their key activities
Split the key activities into small chunks
Organized stories into “minimum viable products” aka releases
Caveats
Good for organizing backlog
Doesn’t explicitly consider value
Useful when desired functionality is known
Not too helpful for true discovery
Use models and stories to describe what to build
User stories are helpful, but not sufficient
CardConversationConfirmation
IndependentNegotiableValuableEstimableSmallTestable
In order to finalize the programAs Connie Conference ChairI need to schedule the accepted sessions into rooms for the conference
Stories are Coupons for a Conversation…
By JB Rainsbergerhttp://www.jbrains.ca/permalink/user-stories-a-ticket-for-a-conversation
Use models to identify storiesIn order to provide feedback to submittersAs ReedI need to submit a review of a sessionAs ReedI can add a review to a sessionSo that I can provide feedback to Sam
As SamI can view reviews on my sessionSo that I can get feedback on my session
As ReedI can edit my reviewSo that I can react to changes Sam made to his submission
Stories represent changes that need to occur
In order to guide submitter track selectionAs Peter Program ChairI want to organize tracks into themes
What I
asked for
The delivery team sets me straight
And comes up with a better solution
Use models to further describe stories
In order to provide feedback to submittersAs ReedI need to submit a review of a session
These are our “stories”.
These are truly placeholders
Acceptance Criteria & Examples
Just Enough Analysis
Do only what you actually need to do
For illustra
tive purposes only
No models were harmed used
building the submission system
Definition of Ready
Team discusses and agrees
Possible things to include
Interaction
Diagrams
Prototypes
Wireframes
Sample Data
Testable example
s
Acceptance
Criteria
State Diagram
sSmall Story
UX Test
ApprovalsDepende
ncy identifie
d
Stakeholders
identified
Definition of Ready
Analyze when youneed to, not before
Discovery and Delivery
Understand the Problem
Learn from Feedback
Deep dive on most valuable
feature
Identify solution
(Features)
Demo/Deploy
Develop/Test
Stories with Acceptance Criteria & Examples
Discovery Delivery
When do we do this stuff?
Create Impact
map
Select next
deliverable from
map
Update Impact
map
Identify stories Further
describe stories
Discovery and Iterative DeliveryD
isco
very
Del
iver
y Deliver iteration 1 stories
Discovery for iteration 2
Support iteration 1 delivery
Deliver iteration 2 stories
Discovery for Iteration 3
Support iteration 2 delivery
Deliver Iteration 3 stories
Discovery for Iteration 4
Support iteration 3 delivery
Planning Identify stories Discovery for
Iteration 1
• Development environment setup
• “spikes”
Iteration 0 Iteration 1 Iteration 2 Iteration 3
Ready Stories
support dev
Customer input in Agile Projects by Lynne Miller
coded
feat
ures
Discovery & Delivery in Flow
Best of Both Worlds
Iteration
Planning
Discovery Board
Delivery Board
Discovery Board
Defn of Ready
Story
Story
Story
StoryStory
Story
Story
Story
Story Story
StoryStoryStory
Story
FeatureFeature
Feature
Feature
Defn of Estimata
ble
Include: Story Acceptance Criteria
Story
Story
Include: Story Acceptance Criteria Size
Include: Story Acceptance Criteria Size Mockup Dependencies Stakeholder list Examples
If you remember nothing else…
Use value to determine the right thing to build
User stories are placeholders. Nothing more
Use models and examples to describe the solution
Collaborate to figure out what is “just enough”
Questions?
Kent [email protected]@BeyondReqswww.beyondrequirements.comSlides available from:http://www.slideshare.net/kentjmcdonald
