Building Better Products Using
User Story Mapping
Jeff Patton
[email protected]
www.agileproductdesign.com
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
User Stories are multi-purpose
Stories are a:
▪ User’s need
▪ Product description
▪ Planning item
* Kent Beck coined the term
▪ Token for a conversation user stories in Extreme
Programming Explained 1st
Edition, 1999
▪ Mechanism for deferring
conversation
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 5
Stories gain detail over time
Start with a title
Add a concise description often using
this useful template:
As a [type of user]
I want to [perform some task]
so that I can [reach some goal]
Add other relevant notes,
specifications, or sketches
Before building software write
acceptance criteria (how do we
know when we’re done?)
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 6
Agile customers or product owner
prioritize stories into a backlog
A collection of stories for
a software product is
referred to as the
product backlog
The backlog is prioritized
such that the most
valuable items are
highest
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 7
User Story Mapping is an an approach to
Organizing and Prioritizing user stories
Unlike typical user story
backlogs, Story Maps:
▪ make visible the workflow or
value chain
▪ show the relationships of larger
stories to their child stories
▪ help confirm the completeness
of your backlog
▪ provide a useful context for
prioritization
▪ Plan releases in complete and
valuable slices of functionality.
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 14
User Story Mapping is an an approach to
Organizing and Prioritizing user stories
Story Maps support the primary intent
of user stories, rich discussion
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 15
The foundational building
block of a story map is the
user task
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 16
People achieve goals through
interaction
problem or
goal
How I’d like to feel, or what
I’d like to achieve
goal evaluation
Is my goal met or problem
resolved?
Take some
action
action evaluation
Did that action deliver the results I
expected?
the world
Information and tools
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 20
Think of three levels: goal, task, and
tool
goal
task
tool
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 22
Software contains features that support
a variety of tasks and a variety of goals
goals
tasks
software
features
tools
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 23
User tasks are decompose to smaller
tasks and organize into activities
Tasks require intentional action on behalf of a tool’s user
Tasks have an objective that can be completed
Tasks decompose into smaller tasks
Tasks often cluster together into activities of related
tasks
“Read an email message” is a task, “Managing email” is an
activity.
read
task
message
manage
activity
email
send prioritize
task
message task
message
create place
task
folder delete task
message
task
message in folder
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 27
Be sensitive to your user task’s
“altitude”
Too abstract
Activity or “Kite level”
Longer term goals often with no precise ending. I’ll
perform several functional tasks in the context of an
activity Think about user
experience at this
level
Functional or “Sea level”
I’d reasonably expect to complete this in a single
sitting
Sub-Functional or “Fish level”
Small tasks that by themselves don’t mean much. I’ll do
several of these before I reach a functional level goal
Too detailed
* from Cockburn’s Writing
Effective Use Cases
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 29
In practice user stories may be written to
describe user tasks or the tools that support them
goals More task-centric:
As a weekend gardener
I want to dig a hole
user story
tasks
so that I can plant a tree
More tool-centric:
(or feature-centric)
software As a weekend gardener
features
I want a shovel
so that I can [dig a hole to]
plant a tree
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 31
What are the goals & tasks?
Business goals or pain
points?
Types of users using
this system?
User’s goals or pains?
How will users of the
system reach their
goals?
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 34
Start with an understanding
or user experience
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 35
A user scenario is a simple way to think
through user experience concretely
A user scenario tells a story about a main character with a
problem or goal
▪ Describes how that character reaches their goal
▪ contains important facts
▪ describes external context
▪ describes goals and concerns of our character
include interesting plot points that help us envision
important aspects of the system
A scenario can gloss over uninteresting details
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 37
Imagine the user experience
as a scenario
Separate your team of four into two pairs
One person imagine out loud the experience of someone using the kiosk. Think about:
▪ Typical use, including typical problems
▪ Interesting plot points
▪ Goals and pains of your user
The other ask questions to better understand
After 5 minutes of discussion write out the scenario
Pair one think about Carol: Pair two think about Isaac:
casual browser Impatient buyer
“I want to find something good “I wan to find a specific hard to find
from a band I heard on the radio.” foreign film.”
Goal: : have fun finding something Goal: : Find it and get out quickly
interesting without wasting my time
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 38
Extract task-centric user stories
from your user scenarios
Come back together as
a team
Reviewing each others
scenarios, extract task-
centric stories using
yellow stickies
Write only the tasks
verb-phrase for your
title
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 39
Organize user stories into a
map that communicates
experience
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 40
By arranging activity and task-centric story
cards spatially, we can tell bigger stories
Tell a big story of the product by starting with the major user
activities the kiosk will be used for
▪ Arrange activities left to right in the order you’d explain them to
someone when asked the question: “What do people do with this
system?”
time
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 41
By arranging task-centric story cards
spatially, we can tell bigger stories
Add task-centric stories in under each activity in workflow
order left to right.
▪ If you were to explain to someone what a person typically does in
this activity, arrange tasks in the order you’d tell the story. Don’t
get too uptight about the order.
time
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 42
By arranging task-centric story cards
spatially, we can tell bigger stories
Overlap user tasks vertically if a user may do one of several tasks
at approximately the same time
▪ If in telling the story I say the systems’ user typically “does this or
this or this, and then does that,” “or’s” signal a stacking vertically,
“and then’s” signal stepping horizontally.
time
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 43
The map shows decomposition and
typical flow across the entire system
Reading the activities across the top of the system helps
us understand end-to-end use of the system. (Talk
through just these when talking with people with short
attention spans.)
time
Below each activity, or large
story are the child stories
that make it up
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 44
Building a story map helps facilitate
discussion – but requires a bit of space
Gary Levitt, owner & designer of Mad Mimi
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 45
A story map for a reasonable sized system
can fill a room
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 46
Assemble your harvested task-centric
stories into a simple story map
Work as a team to organize your stories
Look for activities: tasks that seems similar, are done by similar
people in pursuit of similar goals
Use a different color sticky to label activities
time
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 47
Discuss, fill in, refine the
map, and test for
completeness
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 48
Once you’ve got the idea down, it’s quick to record
stories as you discuss the experience with users
Discuss the steps of the process with candidate users
▪ Record tasks as they say them
▪ Rearrange tasks and insert tasks as you clarify the big story
▪ Add activities as you identify them from discussion
time
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 49
As details emerge in conversation, trap
them under their associated task cards
Record details so they’re not lost, and so those who
you’re working with know that you’re listening
▪ Consider tucking them under tasks cards to “hide them”
from the discussion
activity
time
task
sub-tasks or
task details
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 50
By arranging activity and task-centric story
cards spatially, we can tell bigger stories
Add a vertical axis to indicate necessity
Move tasks up and down this axis to indicate how necessary they are
to the activity.
▪ For a user to successfully engage in this activity, is it necessary they
perform this task? If it’s not absolutely necessary, how critical is it?
time
necessity
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 52
By arranging activity and task-centric story
cards spatially, we can tell bigger stories
Test the Story Map by telling bigger stories with it
▪ Choose an activity to start with
▪ When reading left to right use the conjunction “and then” to connect cards in the story
▪ With cards in the same row use “or” to connect cards in the story
▪ For cards below the top, “absolutely necessary” axis, use the phrase “might optionally”
to communicate optionality
▪ Chose a concrete user name to help tell the story
time
necessity
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 53
By arranging activity and task-centric story
cards spatially, we can tell bigger stories
“Steve knows the title of what he’s looking for. He steps up to the
kiosk and searches by title. Optionally he might have searched by
artist. After seeing titles that match what he typed in, Steve views
the price new and used, and then views the status – whether it’s in
stock or not. He notices it’s in stock as both new and used, so then
Steve views the location in the store for the used title.”
time
Notice the bold faced user tasks from our
story map
Notice the conjunctions that knit the cards
together into a longer story
necessity
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 54
Discussions over story maps help drive
out more details
Repeated review of the story map with multiple users and
subject matter experts will help test the model for
completeness
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 55
The user story map contains two
important anatomical features
The backbone of the application is the list of
essential activities the application supports
The walking skeleton is the software we build that
supports the least number of necessary tasks across
the full span of user experience
The backbone
time
The walking skeleton
necessity
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 56
Using discussion, fill in your story map
Work together as a team
Look for alternative tasks
▪ What else might users of the system have
done that didn’t come up in your scenarios?
Look for exceptions
▪ What could go wrong, and what would the
user have to do to recover?
Consider other users
▪ What might other types of users do to reach
their goals?
Knit al these additional stories into your
map
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 57
Slice the map to find ideal
incremental releases
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 58
Agile teams plan product construction
in layers
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 59
Agile teams plan product construction
in layers
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 60
Release
Product How can we release value
incrementally?
or Project What subset of business
What business objectives will each release
objectives will the achieve?
product fulfill?
What user constituencies will
Product Goals the release serve?
Product Charter
What general capabilities (big
Customers stories) will the release offer?
User Personas Release Roadmap
Target Customers
Iteration or Target Personas
Sprint Story (Backlog
What specifically will we
build? (user stories)
Item)
How will this iteration What user or stakeholder need will
move us toward release the story serve?
objectives? How will it specifically look and
Iteration Goal behave?
Development or How will I determine if it’s completed?
Construction Tasks
Story Details
Acceptance Tests
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 61
Given story map organized vertically by
necessity, we need only slice to plan
time
necessary
first release
less
optional second release
optionality
more third release
optional
Choose coherent groups of features that consider the span of business
functionality and user activities
Support all necessary activities with the first release
Improve activity support and add additional activities with subsequent
releases
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 62
Given story map organized vertically by
necessity, we need only slice to plan
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 63
Adding tape lines to the wall lets
participants organize stories into layers
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 64
Adding tape lines to the wall lets
participants organize stories into layers
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 65
Planning incremental releases can be
facilitated as a collaborative event
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 66
Guidelines for releasing on time
Thin stories aggressively during early sprints to
build all essential functionality early.
Build up functionality only after all necessities
are in place.
Protect time in the final sprints for product
refinement.
Assess release readiness at the end of each
sprint as part of product review.
© Jeff Patton, all rights reserved, www.AgileProductDesign.com 101
Building Better Products Using
User Story Mapping
Jeff Patton
[email protected]
www.agileproductdesign.com
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
