Objectives

• Run a simple user journey
• Break down journey into stories
• Create stories to be built in a sprint
• Questions

The Journey

• The name “user story” comes from the idea that we should tell the “story” of what’s needed and why it’s valuable and not just document requirements

Users:

Users think of the stories
as descriptions of their needs

Business people think of them as product features
that will generate return on investment.

Developers think of them as the specifications
for software to build

Testers

think of them as things they need to validate.

Project managers think of them as

work to schedule into a release.

A good story map

keeps conversations
about your product alive and productive
throughout its construction

In telling the story, we’ll arrive at
a better idea of what to build.

Extra-specific details cloud the conversation

and erode the value of the story.

Size

User stories that describe only a
small chunk of software are quicker
to code and test and, when completed,
show progress.

Showing progress in the
form of working software is an important
characteristic of agile development.

A backlog that really supports conversation

has three important qualities:

Descriptive

It helps us understand
the users and their needs and how the software addresses those needs.
It helps us visualize the entire product

Right sized

High-level conversations
have high-level stories; detailed
conversations have more detailed stories.

Conversations must be enabled at
the executive level and at the detailed
development level.

Prioritized

The most valuable items,
the ones we need to focus on first, can
easily be identified.

Order

• reflects the user’s workflow order or business process
• allows us to tell a meaningful story about a significant part of the entire system without getting lost in the details.

“user task” to describe

things a user would like to accomplish.

User tasks usually start with a

verb to help us understand what they’re

doing. We’ll call these “task-centric user

stories.”

At this point, they’re all

too big and too poorly understood to be

built, so don’t get caught up in the epic

versus story distinction

beginning story map a mile wide and
an inch deep.

For developers and
testers who may be used to focusing
on the details, this may be the first time
they’ve seen the big picture

Additional REsources

• Mike Cohn: User Stories Applied
• Jeff Patton: Telling better user stories

As you fill in and validate the map,
you’ll add, split, reorganize, and annotate
stories with details and cool solution
ideas

Plan releases

Untitled Slide

Knowing the goals of a

first release allows me to focus on what

to build in that first release

I’ll target

functionality that helps me learn fast

about the product

The trick

to prioritization is not to work with the
stories first but to work outside in the
product’s context.

the customers and users of our product

and the business strategy that motivates
building the product.

We have previously identified a few
user types such as frequent business traveler
and family vacation booker. Start by
prioritizing those

Are we
trying to build the best business travel
site on the Web? Or, do we think that
the vacation planner is an underserved
market and we’d do best to focus on
them?

These sorts of decisions are strategic
business decisions. Don’t try to prioritize
details about what to build until
you’re clear on the business strategy

Untitled Slide

Business stakeholders ideally will
make strategy decisions informed by
market research, revenue- or cost-saving
goals, or other considerations. Once
those decisions are made, we can see
more clearly which users are most critical
to realizing our business strategy.

The left-to-right organization of the
story map supports good discussion.
The top-to-bottom organization shows
decomposition. When it comes time to
build specific bits of sofware, it’s the
smallest detail stories that we’ll want to
build, so they’re the ones we’ll prioritize
into releases.

First, post
and discuss the business strategy and organize
the user types into priority order.

Untitled Slide

Then, create slices in our story map by
adding tapelines left to right to create
horizontal slices, each representing a release.

Focus on identifying the smallest first slice that will support your
target user and business strategy

Untitled Slide

While planning, we may split stories,
add more stories, reword stories to make
them clearer, or reorganize the map to
better support discussion.

We can test a slice’s coherence
by walking it left to right and
talking through a user’s experience.

If
we start with our highest priority user
and describe his experience, pointing out
stories as we go, we do so only by discussing
stories inside the release slice

If
we can’t tell the big story of our user’s
experience with the first release without
dipping down into second-release functionality,
then we know we have not included
sufficient functionality

When you’re comfortable with a release
plan, you can summarize each slice
or release by giving it a name, writing a
couple of short sentences expressing the
business benefit for building it and what
the user’s benefit is when using it.

This
list of names and benefits—along with
a few bulleted, high-level stories—is our
product roadmap.

Build

During product construction, keep
the story map visible so it can help give
context to further detailed discussions.
Ignore the slices for releases other than
the one on which you’re working.

Break
the current release again into three
thinner slices. Using a chess game metaphor,
I call the slices “opening game,”
“mid game,” and “end game.”

Untitled Slide

The opening game slice contains the
simplest possible functional version of
the product.

Remember, we’re not releasing
yet, so it doesn’t need to be release
ready. But, it should help us validate our
functional scope, our architecture

at the end, be able to support end-to-end
performance and load testing.

It ideally
contains a little bit from every major activity
in the system. I refer to these activities
as the “backbone” and this very
thin, not quite releasable product, as our
“walking skeleton

Mid game stories focus on getting the
system to full functional completeness.
It’s important in mid game to ramp up
the amount of validation we do with
users and with the system architecture

End game stories focus on polish, fit,
and finish. We’ll need to make sure we
have time during end game to accommodate
all the “predictably unpredictable”
work that comes in as a result of the
user validation and other testing we’ve
been doing.

Final

Keep visible your business strategy,
target user types, release roadmap, and
user story map

Mark off stories that are
done. Discuss how ready your product is
to release at a high level, user activity by
user activity.

Use the map to pull your
attention away from the minutia of dayto-day
work and back to the big picture
of the product you’re growing.