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.
9. 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
33. Caveats
Good for organizing backlog
Doesn’t explicitly consider value
Useful when desired functionality is known
Not too helpful for true
discovery
35. User stories are helpful, but not
sufficient
Card
Conversation
Confirmation
Independent
Negotiable
Valuable
Estimable
Small
Testable
In order to finalize the
program
As Connie Conference Chair
I need to schedule the accepted
sessions into rooms for the
conference
36. Stories are Coupons for a
Conversation…
By JB Rainsberger
http://www.jbrains.ca/permalink/user-stories-a-ticket-for-a-conversation
37. Use models to identify stories
In order to provide
feedback to submitters
As Reed
I need to submit a review
of a session
As Reed
I can add a review to a
session
So that I can provide
feedback to Sam
As Sam
I can view reviews on my
session
So that I can get
feedback on my session
As Reed
I can edit my review
So that I can react to
changes Sam made to his
submission
38. Stories represent
changes that need to
occur
In order to guide
submitter track selection
As Peter Program Chair
I want to organize tracks
into themes
49. Possible things to include
Interaction
Diagrams
Prototypes
Wireframes
Sample
Data
Testable
examples
Acceptance
Criteria
State
Diagrams
Small Story
UX Test
Approvals
Dependency
identified
Stakeholders
identified
Definition of Ready
51. 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
52. When do we do this stuff?
Create
Impact
map
Select next
deliverable
from map
Update
Impact
map
Identify
stories
Further
describe
stories
53. Discovery and Iterative DeliveryDiscoveryDelivery
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
supportdev
Customer input in Agile Projects by Lynne Miller
55. Best of Both WorldsDiscovery Board
Delivery Board
56. Discovery Board
Defn of
Ready
Story
Story
Story
Story
Story
Story
Story
Story
Story Story
StoryStory
Story
Story
Feature
Feature
Feature
Feature
Defn of
Estimatable
Include:
Story
Acceptance Criteria
Story
Story
Include:
Story
Acceptance Criteria
Size
Include:
Story
Acceptance Criteria
Size
Mockup
Dependencies
Stakeholder list
Examples
57. 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”
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.Learning Objectives* Learn how techniques such as Impact Mapping can help you narrow your focus and test your assumptions* Learn how to use analysis models to identify, and further explain user stories* Learn how to establish a definition of ready for your effort and use it to determine "just enough" business analysis
Do we have a complete solution?Are we building things we shouldn’t?
Understand the problem to solve (state it as a goal)Discover possible solutions (options) –impact mappingIdentify the best solution (make assumptions about which has the biggest impact)Transfer the knowledge of that solution to the whole team (Models and stories) Why are you doing the effort? What problem are you trying to solve? Is the problem worth solving? - Make it measurable. This is the value you are seeking to deliver.What are the different things that you can do to realize that value. Impact Mapping is one technique that can get you that information. Creating the map generates options.Which of those options seems the best to help you realize the value – prioritizing the items on the impact map.Use analysis models to describe the option, user stories to identify the changes needed to enact the option, and the models again to further describe the stories.***********We first describe the problem we are trying to solve in terms of some measurable goal. Looking at this goal and comparing it against our decision filters from strategy tells us if the problem is worth solving.We then use Impact Mapping to identify possible solutions. (Grow the Map) and then prioritize the map to identify good solutions. Of course we implement those solutions to determine if they are viable and will result in the impact we want, and to verify assumptions we are making.
Add some animation hereTo talk about how do you get there.
Why are we doing this?
Who can produce the desired effect and who can obstruct it?
Ask audience for possible storiesAsk audience for suggestions of splitting into smaller stories.
Even though I teach people to do this, I sometimes need a reminder… And it can come from anyone on the team.
Green – in estimate deliveredBlue – not in estimate, delivered
Remember to ask the people consuming the information what they need in order to move forward.
CoreKanban PrinciplesVisualize workflowLimit WIPMeasure & Manage FlowMake process policies explicitIdentify & implement improvement opportunities through Lean and related principles and practicesEmergent PropertiesManage QuantitativelyPrioritize by (opportunity) cost of delayOptimize value with classes of serviceManage risk with allocation of capacityEncourage process innovation