Build – Measure – Learn is one of the most important mechanisms of agile software development. However, this mechanism is often crippled in nowadays projects, where traditional approaches of requirements gathering are bloating up product backlogs that cannot be prioritized anymore in a meaningful way. The results are customers not interested in iteration results, release to production that happens only at the end of the project, and feedback from customers when it is already too late and the budget is burned up. Story mapping is a method that aligns user stories along desirable outcomes, so that customers can give sooner meaningful feedback, and release to production can happen earlier. The method helps slicing and prioritizing user stories, and addresses the product design aspect that is missing when just working with a product backlog. The method is highly visual and facilitates shared product ownership among product owner, team and customer. This presentation provide an introduction to the concept of story mapping, with examples and experience gathered in own projects.

1. CHRISTIAN HASSA (CH@TECHTALK.AT)
TWITTER: @CHRISHASSA
Budapest Agile MeetUp, May 9th 2013
Story Maps in practice
enable early feedback to build what really matters

2. 2
About TechTalk
• Agile consulting and delivery
• Offices: Vienna, Budapest, Zurich
TechTalk Team

3. 3
Why agile requirements?
Successful problem solving requires
finding the right solution
to the right problem.
Russell Ackoff, 1974
We fail more often,
because we solve the wrong problem
than because we get the
wrong solution to the right problem.

4. 4
User Stories

5. 5
• Describe user needs or features
• Unit of planning/prioritization
• Future options for evolving the system
• Reminder for a conversation
• Deferring detail to the last responsible
moment
What makes user stories agile?
„User stories are really the artifact
at the heart of the continuing dialog between
what is possible and what is desirable.“
~ Kent Beck (http://c2.com/cgi/wiki?UserStory)

6. 6
Impact Mapping
Story Mapping
Specification-By-Example
Discovering the problem to solve
Why?
How?
Code
Acceptance
Criteria
Epics
Deliverables, Outputs
Impacts, Outcomes
Easier to define upfront Harder to define upfront
User Activities
User Stories
Examples
Goals

7. 7
Specification-By-Example
Defining experiments
Story Mapping
User Activities
Impact Mapping
Why?
How?
Code
Acceptance
Criteria
Epics
Deliverables, Outputs
Impacts, Outcomes
Easier to define upfront Harder to define upfront
User Stories
Examples
Goals

8. 8
delivering software
that generates
Impact

9. 9
Impact Mapping
From: Gojko Adzic: www.impactmapping.org
Based on:
Ingrid Domingues,
Mijo Balic
Effect Managing IT
“Impact Mapping helps us plan better!
It is collaborative, visual and fast.”

10. 10
Impact Map structure
Goal
Actors
Impacts
Deliverables
What is our goal?
Sell 10.000 books within the first 6 months
after launching the business.
Who can help/prevent us reaching our goal?
Shopper of mainstream books,
Shopper of rarely available books,
Shipping Department, Hackers
Impact triggering behavior change to help/obstruct goal
Shopper of mainstream books:
• Receive books quicker
• find popular books more easily
Deliverables or features supporting/preventing
these impacts (behavior changes):
Shopper of mainstream books:
• Receive books quicker
• order books online
• semi-automated distribution center

11. 11
Defining Impacts as User Stories
As a Shopper of mainstream books
I want to order books online
So that I can receive books quicker.
Sell 10.000 books within the
first 6 months
after launching the business.
Actor Impact Deliverable
Actor
Impact
Deliverable

12. 12
Defining Goals
• Scale: What to measure
• (Alternative scales to consider)
• Meter: How to measure
• (Different options how to meter)
• Levels
• Benchmark: Current Situation
• Constraint: Break-Even for
Investment, Minimum Acceptable
Result
• Target: Desired Result
• (Further possible levels: Trend, Fail,
Record, Survival)
# Monthly orders
of books
Sell 10.000 books in the
first 6 months
Shop system
database
0
1.000
10.000
Tom Gilb: Competitive Engineering, PLANGUAGE

13. 13
Combining Goals
Selling books in
6 months
Development+
Operational
Costs
Returning
customers
Scale # Monthly orders of
books
Team Salaries +
Operation Costs
% of Customers
ordering for a
second time
within 2 months
Meter Shop System
database
Financial
Accounts
Shop System
Benchmark
Constraint 1.000 EUR 200.000 20%
Target 10.000 EUR 100.000 50%

14. 14
Evolving goals over time
Selling books in
6 months
Development+
Operational
Costs
Returning
customers
Scale # Monthly orders of
books
Team Salaries +
Operation Costs
% of Customers
ordering for a
second time
within 2 months
Meter Shop System
database
Financial
Accounts
Shop System
Benchmark
Constraint 1.000 EUR 200.000 20%
Target 10.000 EUR 100.000 50%
Increasing book
sales in 6 months
Development+
Operational
Costs
Returning
customers
Scale # Monthly orders of
books
Team Salaries +
Operation Costs
% of Customers
ordering for a
second time
within 2 months
Meter Shop System
database
Financial
Accounts
Shop System
Benchmark 7.500 EUR 180.000 27%
Constraint 15.000 EUR 200.000 20%
Target 50.000 EUR 100.000 50%

15. 15
Brainstorming experiments

16. 16
Story Maps

17. 17
Impact Mapping
Specification-By-Example
Optimizing and refining scope
Story Mapping
Why?
How?
Code
Acceptance
Criteria
Epics
Deliverables, Outputs
Impacts, Outcomes
Easier to define upfront Harder to define upfront
User Activities
User Stories
Examples
Goals

18. 18
Incremental development
1 2 3 4 5
Requires specifying the solution in detail upfront.
Hard to estimate, errors are hard to correct, no
adaption possible.
Hard to provide feedback on incremental
shipment.
From: Jeff Patton, Story Map Workshop

19. 19
Iterative development
1 2 3
Allows to refine the solution.
Allows for feedback to better understand the
problem.
4 5
From: Jeff Patton, Story Map Workshop

20. 20
Story Maps
• Concept by
Jeff Patton
• Prioritize for
impact/outcome
• Optimize design
for user goal
• Inject features to
support user
scenario

21. 21
Building story maps
Impact: Shopper of
mainstream books
receive books quicker
Find book
I want
Collect
books
Commit
order
Wait for
book
Receive
book
time
browse
best
sellers
put into
basket
enter
address
receive
delivery
slip
receive
delivery
notificat.
pay with
credit
card
search
book by
title
create
wish list
inquiry
order
status
Deliverable achieving impact
(Scenario delivers output)
user
activities
system
features
necessity
Order books online

22. 22
Walking
skeleton
Enabling
build – measure - learn
Find book
I want
Collect
books
Commit
order
Wait for
book
Receive
book
time
browse
best
sellers
enter
address
receive
delivery
slip
pay with
credit
card
search
book by
title
create
wish list
inquiry
order
status
put into
basket
receive
delivery
notificat.
necessity
manual
workaround
omitted
steps
Does the deliverable
achieve the impact?
Impact: Shopper of
mainstream books
receive books quicker
Order books online
Does the impact
help the business goal?

23. 23
Iterative delivery of features
Base Requirements
Minimum for demo. „walking skeleton“. Not for production.
Example: Form with mandatory fields without validation.
Capability and Flexibility
Variations of usage. Additional functions, sub-functions.
Example: lookup-control, optional fields
Security
Security for users and stakeholders
Examples: Input validation, additional business rules
Usability, Performance
More efficient, attractive, easier to use
Example: auto-complete, UI-design, hotkeys
From: Jeff Patton, Story Map Workshop

24. 24
Iterative planning for the release
• Opening Game: simplest possible path,
„Walking Skeleton“
• Mid Game: flexibility, capability and security
• End-Game: fine-tuning, performance,
buffer for unexpected
time
uncertainty decreases over time
uncertainty
Opening
Game
Build up
necessities
Mid-Game
Build out flexibility
and business rules
enforcement
End-Game
Refine the UI and
interactions, take
advantage of
iterative learning
From: Jeff Patton, Story Map Workshop

25. 25
Realized business value
End Game
Fine-tuning in the
end.
Mid Game
Build features.
“Meat” for the
“walking skeleton”.
Opening Game
Focus on
understanding the
problem. Are we
building the right
product?
time
realizedbusinessvalue
From: Jeff Patton, Story Map Workshop

26. 26
Learning curve
End Game
Fine-tuning in the
end.
Mid Game
Build features.
“Meat” for the
“walking skeleton”.
Opening Game
Focus on
understanding the
problem. Are we
building the right
product?
time
acquiredproductknowledge
From: Jeff Patton, Story Map Workshop

27. 27
Story Map Example: eVoting System
Provision and support
Nominate candidates
Vote and determine results

28. 28
Sprint 1
Nominate candidates

29. 29
Sprint 2
Nominate candidates

30. 30
Sprint 3
Vote and determine results

31. 31
Sprint 4
Provision and support

32. 32
Not implemented functionality

33. 33
Added functionality

34. 34
Creation of Story Maps

35. 35
Product Design with Story Maps

36. 36
Tools

37. 37
Transport and Conservation

38. 38
Linking within ALM
Refinement for
Sprint planning
Link with Sprint Backlog
(Tasks, Taskboard, Burndown)
Drill into Details
(Specification-By-Example)

39. 39
Summary
Impact Maps
• Define business goals
• Brainstorm impacts on actors to support
(not obstruct) business goals
• Evaluate deliverables achieving impact
Story Maps
• Prioritize a deliverable to achieve impact
• Optimize a deliverable for user goal
• Inject features to support given user scenario

40. 40
Books
Gojko Adzic
Impact Mapping

41. 41

42. 43
Further information
• SpecLog: www.speclog.net
• XP Conference Vienna: xp2013.org, June 3rd-7th
• Agile Trainings: www.techtalk.at/scrum-trainings
Gojko Adzic, Mitch Lacey, Gaspar Nagy
• Q&A: after the Pizza
• Email: ch@techtalk.at – Twitter: @chrishassa
Working at TechTalk
jobs@techtalk.hu - http://experts.techtalk.at
http://www.techtalk.at/TechTalk/Jobs.aspx