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.

1. Analysis in Agile:
It’s More Than Just User Stories
Kent J. McDonald
@beyondreqs

2. What does business analysis look like
in Agile?

3. Agile approaches describe delivery
Where does this come from?

5. And then a
miracle occurs

6. Voila! A Backlog.
But there may be
some problems…

7. Do you have a complete
solution?

8. Is the backlog more
like a wish list?

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

10. VALUE
INPUTS
INPUTS
PROCESS
Use value to
determine the right
things to build
OUTPUTS
VALUE

11. An example would be
handy right about now

12. Enterprise System Replacement
New
System

13. Initial Approach to Analysis
New
System

14. New Approach to Analysis
New
System

15. Impact Mapping
© Gojko Adzic 2012
For more information:
impactmapping.org

16. Goals

17. Why are we doing this?
© Gojko Adzic 2012

18. Actors

19. Who can produce the desired effect
and who can obstruct it?
© Gojko Adzic 2012

20. Impacts

21. How should our actors behavior
change?
© Gojko Adzic 2012

22. Deliverables

23. What can we do as
a delivery team to
support the
required impacts?
© Gojko Adzic 2012

24. © Gojko Adzic 2012

25. Validating assumptions
© Gojko Adzic 2012

26. Identifying user stories
© Gojko Adzic 2012
IMPACT

28. Story Mapping

29. Identified our personas

30. Identified their key activities

31. Split the key activities into small
chunks

32. Organized stories into “minimum
viable products” aka releases

33. Caveats
Good for organizing backlog
Doesn’t explicitly consider value
Useful when desired functionality is known
Not too helpful for true
discovery

34. Use models and stories to describe
what to build

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

39. What
I
asked
for

40. The delivery team sets me straight

41. And comes up with a better solution

42. Use models to further describe stories
In order to provide
feedback to submitters
As Reed
I need to submit a review
of a session

43. These are our “stories”.
These are truly
placeholders

44. Acceptance
Criteria &
Examples

45. Just Enough Analysis

46. Do only what you actually need to do

47. Definition of Ready

48. Team discusses and agrees

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

50. Analyze when you
need to, not before

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

54. Discovery & Delivery in Flow

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”

58. Questions?
Kent McDonald
kentjmcdonald@gmail.com
@BeyondReqs
www.beyondrequirements.com
Slides available from:
http://www.slideshare.net/kentjmcdonald