User Story Maps: Secrets for Better Backlogs and Planning

Building Better Backlogs with
User Story Mapping
comakers

2comakers, LLC :: hello@comakewith.us

3comakers, LLC ::
Now and Later
3
Now and Later photo: Jay Malone via Flickr
http://www.flickr.com/photos/jcorduroy/3725077603/
Turn and talk with someone
at your table:
What challenges do you have
today with user stories?
If you’re not working with
agile development, what
challenges do you have with
project requirements?

What we’ll cover
Stories and Story Maps
What’s a story map
Everything you need to know about stories, but were
afraid to ask
Story Mapping in Agile Process
Building the backbone
Filling in and validating
Prioritizing and planning

6
The Story Map

A Story Map helps facilitate discussion
about user’s experience with our
product
Gary Levitt, owner & designer of Mad Mimi
7
details•smaller steps•alternative steps•UI details•technical details
details•smaller steps•alternative steps•UI details•technical details
workflow(from the user’s
perspective)
workflow(from the user’s
perspective)
backbone(gives structure to themap)
backbone(gives structure to themap)
product goals
(why build the
product)
product goals
(why build the
product)
users
(what are their goals)
users
(what are their goals)

Story maps aren’t an invention, they’re a
pattern
David Hussman Story
Jamming
Narrative Journey
Map courtesy
Duncan Brown of
the Caplin Group
Indi Young’s
Mental Model
Todd ZakiWarfel’s
Task Analysis Grid

Key concepts
Sketch a quick image/diagram for each, based on what you
remember
story map
backbone
other types of maps

10
What you need to
know about user
stories

11comakers, LLC :: hello@comakewith.ushttp://www.cakewrecks.blogspot.com
Specifying in writing
doesn’t work well

user
Stories facilitate a conversation with a
goal of shared understanding
developer

Stories have a simple lifecycle
! ?
Card
Conversation
!
Confirmation
Consequences
! ??
!
Construction
* Ron Jeffries coined the
3 C’s in Extreme
Programming Installed

14
BA
comakers, LLC :: hello@comakewith.us
user
testerPM
UX Designer
Stories need to support lots of
conversations across lots of project roles
developer
business leader

User Stories are boundary objects
Here’s the fine print on boundary objects:
“A boundary object is a concept in sociology to describe information used
in different ways by different communities. They are plastic, interpreted
differently across communities but with enough immutable content
to maintain integrity” --Wikipedia
“They are weakly structured in common use, and become strongly
structured in individual-site use. They may be abstract or concrete.
They have different meanings in different social worlds but their structure
is common enough to more than one world to make them recognizable
means of translation. The creation and management of boundary objects
is key in developing and maintaining coherence across intersecting social
worlds.”
-- Leigh & Griesemer

First we need to agree on
why we’re here
Our job is to change the
world
really, I’m not kidding

How to change the world

19© 2011 Jeff Patton, all rights reserved, www.AgileProductDesign.com
Agile stories are about the future world
we imagine
As a
I want
so that

Imagine the future
Who are the users and
what benefit do they get?
What will users do in the
future using your software?
Why should your
organization build the
software? What benefit
will they get?

Stories gain detail over time and from
conversation - don’t add all your details at
once
Start with a short title
Add a concise description
some use 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?)

That story’s
too big!
That story’s
too big!
Stories should describe
software that can be
built in a couple days

I’m not
really getting
what this
product is
about!
I’m not
really getting
what this
product is
about!
When considering a
product a story at a time
it’s easy to lose the big
picture

24comakers, LLC ::
There’s no right size for
stories for all conversations

user
product
manager
The natural “unit of measure” for stories
varies by conversation
BA or
UI Designer
developer
business
leader

release cycle
development
cycle
User Stories shrink in size and grow in
detail as they travel through a pipeline
Capabilities
or features
•Name
•Target customer or
user
•Value
Release-
sized stories
•Target release
•Relative size
•UI sketches
•Rough acceptance
tests
Stories for
upcoming
iterations
•Priority
•UI design
•Business rules
•Acceptance tests
Iteration-
sized stories
•Detailed
acceptance tests
•Small enough to
complete in an
iteration
Working
tested
software
•Meets the team’s
definition of done
Validated
product parts
•Vetted with customers
and users
•Evaluated for release
readiness
Minimal
releasable
software
•Generates value
from its use

release cycle
development
cycle

release cycle
development
cycle
Just-in-time
Refinement
Continuous
Integration

Key concepts
Ask someone to explain the one that stands out the most for them, then
switch and have them ask you.
agile user story
boundary object
output, outcome, &
impact
the canonical story
template
what, who, why
story size
the story funnel

Story maps are built during a product
discovery phase
what:
who:
why:
what:
who:
why:
User Story Map
R1
User Story Map
R2
R3
Opportunity
Backlog
Contains valuable product
and feature ideas
Product
Discovery
Research, explore, validate
and plan delivery of potential
product solutions
Product Delivery
Iteratively and incrementally
build and validate product
solutions
what:
who:
why:
R2what:
who:
why:
R3what:
who:
why:
R1
User Story Map Product Backlog
Product
Goals
Simple
Personas
User Interface Sketch

31
Starting a map

32comakers, LLC ::
Before mapping identify
relevant context
Business
Strategy
Customer
Segments
Users & user
goals
Product
usages
Regulatory
constraints
Legacy product
and architecture
?What else?

What, who, and why
What: name the product,
feature, or capability you’re
thinking of
Who: name the choosers
and users who will buy and
use the resulting solution
Why: say how the
organization paying to build
the software benefits -
describes pains today or
desired outcomes
Collaboratively sketch simple
pragmatic personas
Stickyminds.com article: Pragmatic
Personas
http://www.stickyminds.com/s.asp?F=
Identify measurable product goals
http://agileproductdesign.com/writing/patton

Build the backbone of
your map by:
1. Discussing experience
and then mapping

Building a backlog as a story map is a
discussion about user experience, not user
stories

Build the backbone of your
map by:
2. Brainstorming user’s
tasks then organizing
(Ask a group of users to list all
the things they do as part of a
business process)

37comakers, LLC :: hello@comakewith.us 37

Build the backbone of your map
by:
3. Researching, observing,
designing, and then extracting
stories from a narrative
(A narrative like a use case or user
scenario describes what people do to
reach their goals. Extract the verb
phrases from a narrative)

Harvest tasks from scenarios
Field Manager enters daily performance reports
The shift has just ended and his reps are coming up with their totals.
They have printed sheets with totals written on them. Steve
quickly looks them over and signs them off. His assistant
manager brings him other sheets with totals he’s signed off.
In between visits by reps, Steve opens his Field Manager
Workbench on his laptop. After logging in he sees today’s date
and the planned number of applications his reps should be
gathering – 180 for today.
He also sees yesterday’s numbers, and last week’s numbers, and
the last 30 days in graph that shows applications relative to
approval rate. Last week’s numbers were bad, and it’s the last
week of the month, so Steve knows he’s got to do well today.
Steve clicks “enter rep performance data.” He shuffles his reps
performance sheets and grabs the first one.
5. The date is defaulted to today, and the shift is defaulted to ‘morning’
since he hasn’t yet entered info for today. Steve begins to enter the
reps name, but after a few characters the system auto-completes his
name.
6. The rep’s ID is already filled in, along with the code for the credit card
promotion they’re working on today.
7. Steve fills in the shift information for his rep. He then enters the total
number of applications taken.
8. It looks like from the notes on this sheet that this rep left sick two hours
early. Steve adds a note about this in the system.
9. Time passes as more reps bring in their sheets and Steve completes
entering them in between conversations.
10. After all the sheets are done, Steve looks at a summary screen for the
day. It looks like he’s close to his goal. If the next shift continues at
this rate he’ll beat the plan by 5% or so. That’s good.
11. Steve validates that the base pay is correct at $5 per app, and that
he’s set an individual bonus giving reps $50 each if they reach 20
apps. Next to each rep he sees the calculated pay, base, bonus, and
total pay for the day.
12. The annual sale at Macy’s has brought a lot of people in today. Steve
chooses a “sale increases mall foot traffic” code to add to his shift data
sheet. Frank, his boss, has pestered him to make sure he includes
this type of information in his daily summaries.
Steven
Credit Card Marketing Field
Manager
Steven is a field manager working
at the local shopping center.
He’s in the middle of a long
workday supervising 13 reps
who are busy talking to people
trying to convince them to
apply for a credit card.

A narrative imagines the experience of a
product that doesn’t yet exist
UI Storyboard from Margarete Fuss, SAP AG

Story map under a story board
Photo courtesy of Carbonite, Boston, MA
41

Think:
“mile wide inch deep”
or
“breadth not depth”
You’re trying to get the big
picture

Key concepts
Think and write your own definitions in, based on what you
remember
product context
pragmatic persona
measurable product
goal
building the backbone
mile-wide inch-deep

44
Filling in and
Validating

Discuss, fill in, refine the
map, and test for
completeness

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

47
add, rewrite,split,combine,reorganize
add, rewrite,split,combine,reorganize
comakers, LLC :: hello@comakewith.us
Play “wouldn’t it be cool if...”
Look for variations
 What else might users of the system have done?
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?
Add in other product details

Key concepts
Stand and stretch. One person will explain a concept while doing a simple
stretch. The rest of the group will copy the stretch.
filling-in through
discussion
variations
exceptions
idea
details
other user types

49
Planning incremental
product releases

Prioritize stories vertically
then “slice” to small
valuable releases

Adding tape lines to the wall lets
participants organize stories into layers
51

Maps have latitude and longitude
52
sequence
(time from the user’s perspective)
priority
(time from the
planner and
builder’s
perspective)

Planning incremental releases can be a
whole team event
53

Releases target business outcomes,
customer, and user segments
* Menlo Innovations organizes personas into a target to help focus releases

Use target personas to drive release
strategy
Target a primary persona for a first release
Try a “good-better-best” strategy

Minimal Viable Releases target success
for a product with a specific target
audience
MVP: Minimal Viable Product
MMF: Minimal Marketable Feature
To thin a release, first reduce the size of your target market
MVP
1 or more
MMFs

You’ll spend most of your time filling in
and validating

Key concepts
Pop-up and explain a part of the concept. When finished sit down so that
someone else can pop-up and explain. We’ll count how many we get in 3 minutes.
slicing the map
collaborative planning
MVP & MMF
release strategy
discovery phase
features and story maps

59
Mapping experience
(you already know this stuff)

60comakers, LLC ::
Learn by mapping an experience you
know

Use this simple warm up to show
everyone they already know how to map
Step 1 - Brainstorm: List all the things you did to
get ready to be here today
 Starting from the moment you woke up until you
arrived here
 Using sticky notes, write the things you did, one
thing per sticky note

Play along and quickly list all
the things you did to get
ready this morning...

63comakers, LLC ::
We naturally think in tasks

64comakers, LLC ::
There’s a natural “human size”
for tasks
* Cockburn’s Writing Effective Use Cases
describes goal levels for use cases this way

In small groups, organize your stickies into
chronological order - the order things were done - from
left to right
 You’ll merge your different timelines into a single
timeline
 Stack identical stickies (similar things done at similar
times
 Place parts of things under larger things (“wash hair”
might go under “take shower”)
Step 2: Organize

The exercise looks like this
66

People naturally build a
two-dimensional map
67
sub-tasks,
alternatives,
variations, and
details
An imperfect
narrative flow

In your same groups, look for groups of stickies that
seem to go together and create a higher-level label for
those
 All the stuff done in the bathroom could be called
“bathing” and all the stuff done in the kitchen might be
“getting breakfast.”
 You may need to invent some names - what would you
call those things you do to get out of the door?
Gathering laptop, papers, car keys...
Step 3: Find Patterns

69comakers, LLC ::
We naturally group tasks into
activities

Look back across the model of the whole experience.
 What was your favorite part of the morning, your
high point? Write the high point down on a sticky
with a smiley face. Stick it where you think it goes on
the map.
 What part of the morning did you hate? Frustrated
you? Write a note about it with a frowny face. Stick
it where you think it goes on the map.
Step 4: Mark high points and pains

Experience maps describe the world
today
71
* Narrative Journey Map
courtesy Duncan Brown of
the Caplin Group

Experience maps describe the world
today
72
* Narrative Journey Map
courtesy Duncan Brown of
the Caplin Group

The biggest benefit of
modeling this way is not the
data in the model

Often when we verbally discuss ideas, we may
incorrectly believe we have the same
understanding

Representing our ideas as models allows us
to detect inconsistencies in our
understanding

Through discussion and iterative model
building we arrive at a stronger shared
understanding

Using that shared understanding we can
work together to arrive at the same
objectives

Shared understanding is critical to
successful collaborative work

Model collaboratively to
build shared
understanding

Key concepts
Write your own definitions in, based on what you remember
user tasks
goal-task-tool
dependency
task goal level
user activity
experience map
journey map
collaborative modeling

81comakers, LLC ::
Now and Later
81
Now and Later photo: Jay Malone via Flickr
http://www.flickr.com/photos/jcorduroy/3725077603/
What challenges do you have
today with user stories?
If you’re not working with
agile development, what
challenges do you have with
project requirements?
What will you change
about what you’re doing
based on what you’ve
heard?

Building Better Backlogs with
User Story Mapping
Thank you!Thank you!
comakers

User Story Maps: Secrets for Better Backlogs and Planning

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie User Story Maps: Secrets for Better Backlogs and Planning

Ähnlich wie User Story Maps: Secrets for Better Backlogs and Planning (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

User Story Maps: Secrets for Better Backlogs and Planning

Hinweis der Redaktion