A Guide to User Story Mapping:

Templates and Examples (How

to Map User Stories)

Backlogs are exciting. Seeing all those potential features, updates,

and bug fixes all in one place, just full of potential… Yeah, sure.
Right about now you probably think I’m full of something other than
potential.
The truth is that backlogs can be confusing.
It’s all-too-common for your collection of “could dos” to turn into a
roadblock. When there are too many options, where do you even
start?
Plus, by the time your backlog tasks make it to your team, they’re
often left scratching their head. When your backlog is full of high-
level features, they make sense to everyone. But by the time those
features are broken down into sprintable tasks context is lost to
everyone but (maybe) the product owner. To use a cliche: You can’t
see the forest for the trees.
But there’s a better way to make sense of your backlog, prioritize
what needs to get done, and keep the bigger product vision front
and center: User story mapping.
User story mapping is a simple, collaborative exercise that helps
you define your user’s journey with your product., where any gaps
exist, and what it could be. In other words, it’s a way to move out
of feature prioritization purgatory and instead keep your user’s
needs and actual use cases front and center.
Rather than a traditional backlog, story maps show real workflows.
Instead of prioritizing all the small user stories against each other,
story maps let you see everything within the context of your overall
business goals.
In this guide, we’ll run you through the entire process of user story
mapping, from how to write good user stories, to how to set up and
run a user story mapping session, to turning it into a development
framework.

 Let’s start with the basics: What are user stories? And user story
examples?
o What are user stories?
o What are some user story examples?
 User story mapping 101: What it is, who does it, and when it
happens
o Who’s involved in user story mapping?
o When should you map user stories?
 How to create a user story map in 7 steps
o Step 1: Frame the journey
o Step 2: Build your story backbone
o Step 3: Identify and group activities
o Step 4: Break large tasks into subtasks
o Step 5: Fill in the blanks
o Step 6: Prioritize tasks and subtasks (but leave your backbone as
is)
o Step 7: “Slice” groups of tasks into iterations
 How to turn your user story map into a development strategy

Let’s start with the basics: What are user

stories? And user story examples?
Story mapping is a top-down approach that breaks down your
product vision into actionable steps you can prioritize. You can think
of the basic structure of it as a tree. The trunk is your product vision.
The large branches are goals. The smaller ones are activities. And
then the leaves are tasks (or user stories).
So: Vision → Goals → Activities → Tasks → User Stories
Before we get into the actual mapping portion, we need to make
sure we’ve got all the building blocks in place. This means a backlog
of proper user stories to work with.
(If you’re familiar with user stories already, feel free to skip this
section. But a solid foundation and refresh doesn’t hurt anyone.)

What are user stories?

User stories are short, simple feature descriptions told from the
perspective of your users and customers. When it comes to how to
write user stories, the easiest method is to use a simple
formula made popular by Mike Cohn, co-founder of the Scrum
Alliance:
“As a [type of user] I want [some particular feature] so that [some
benefit] is received.”
This format works for a number of reasons. For one, it puts a
product requirement into the first person—meaning you’re thinking
about the actual person using it, not just what needs to be done.
Second, a repeatable template is easier for feature prioritization as
you’re not comparing apples to oranges.
It’s ok if you have disagreements about each section of this. In fact,
as Mike explains it, one of the main benefits of user stories is that
they “strongly shift the focus from writing about features to
discussing them…. These discussions are more important than
whatever text is written.”

User stories strongly shift the focus from

writing about features to discussing
them. These discussions are more
important than whatever text is written.
While it’s the responsibility of the product owner to make sure
there’s a backlog of stories, anyone can write an actual user story.
What’s more important than who actually writes the story is the
discussion it prompts.

What are some user story examples?

The power of this simple template is that it allows you to write user
stories in whatever level of detail you want. At the highest level, this
means writing what the Agile world likes to call “epics”—large user
stories that cover a huge range of functionality. For example: “As a
customer, I can buy the products I want from your online shop.”
That’s a lot to ask from a single sprint or iteration. So these epics
are usually broken down into smaller user stories (sometimes
dozens or hundreds). So for example, you might have user stories
like:
“As a user, I can browse products my color so that I can quickly find
what I’m looking for.”
“As a return user, I can see products I’ve already purchased to help
inform my decision.”

User story mapping 101: What it is, who

does it, and when it happens
With a whole stack of user stories, it’s time to think about how to
organize them, prioritize features, and plan your sprints. By visually
mapping your user stories out, you break the customer journey
down into parts, making sure nothing gets missed and
It can be a lot to take in, so before we get into the process, here’s a
visual look at all the parts of a user story map:

This will make a lot more sense as we go through the process of

creating it. But I find it helps to have a visual anchor beforehand.
There are a number of benefits to approaching your backlog in this
way:

 Puts the user first: It’s difficult to choose a bundle of features that is
both high value and immediately valuable. User maps look at a
product from the user’s perspective, forcing you to put aside “nice-
to-have” features and focus on what provides the most value to
them now.
 Helps prioritize the right work: Seeing every feature and story in the
context of the larger product roadmap and company vision helps
you know what needs to be done now. It also helps you to expose
risks and dependencies and fill gaps.
 Breaks down epics into manageable stories: If you’re having trouble
writing user stories, mapping out your user’s journey can help you
see how everything works together. This is especially helpful when
it comes to breaking down larger stories or epics.
 Delivers new value early and often: When you prioritize iterations
by immediate value to the user, you’ll keep people happy, solicit
better user feedback, and quickly learn what people want.
 Builds team consensus: User story mapping is a team exercise, and
as such, gives everyone a shared view and input into how the user
journey works and why specific features matter more than others.

Who’s involved in user story mapping?

Because you’re dealing with the entire product, from the user’s
experience to the company’s need to the technical requirements,
it’s good to have a diverse group of people in the room with you.
Typically, you’ll want 4-8 people from a few different groups:

1. Domain experts, testers, and UX designers: People familiar with

users and functionality
2. Stakeholders: People with an idea of how the software will earn your
company money
3. Developers: People who know how long this will take to build

When should you map user stories?

Creating a user story map is a lengthy process, but it’s the backbone
of your feature release. Think of it as a major planning session that
kicks off major projects, pivots, or iterations. It’s a level higher than
your usual sprint planning.
However, it’s so versatile that it can be used in many different
phases of a project. You can map user stories during the initial
product vision workshop or apply it to a small feature to provide
context. You can even use it to restructure your seemingly endless
backlog that’s gotten a little mixed up and lost focus after the last
few releases.
In short, user story mapping can be used whenever you need to
make sense of your product’s future while keeping its present state
front and center.

User story mapping can be used

whenever you need to make sense of
your product’s future while keeping its
present state front and center.

How to create a user story map in 7 steps

Creating a user story map takes time. But luckily you can follow a
pretty clear and logical process while doing it. The key here is to
use it as an opportunity to have discussions with team members
you probably don’t interact with too often. If all goes well, everyone
will come out of this session with a deeper understanding of your
product’s vision and how it helps your user’s needs.
What you’ll need: User story maps are physical items (to start). It’s
important to have a dedicated room and some basic supplies like
sticky notes, 3x5 cards, pens, and a giant piece of paper to house
it all.

Step 1: Frame the journey

Before you start mapping, you want to frame the exercise around a
common goal. This could be your product vision or the goal of a
specific feature you’re mapping out.
One of the simplest ways to do this is just to ask: What does our
product do?
If this feels too big or gets too unwieldy, think about some
constraints you can add to your user story mapping session:

 What? What problem are you trying to solve? What product do you
want to build or what feature do you want to add?
 Who? Is there a specific user or user subset you’re building for?
What benefits will each of them get from what you’re creating?
 Why? What’s the benefit to your company for building this feature
or product? How will giving users this add value to the bottom line?

Talk it through and make sure everyone understands

the vision and overarching goal of the user story mapping session.

Step 2: Build your story backbone

Alright, with a vision and some constraints (or not!) it’s time to define
your “backbone.” This is the entire user journey described in high-
level tasks or steps from start to finish. Don’t get too detailed. At this
point, you want to go wide, not deep.
As an example, let’s say we’re building a product that helps
someone book a vacation home. At the highest level, the steps they
take are:

1. Sign up for an account

2. Search for vacation homes by city/price/location/availability
3. View the home profile page
4. Enter payment information
5. Book home
6. Write a review for the homeowner

Your product is probably more complicated than that. And so there

are a few good ways to help define your backbone.

 Ask an expert to tell a story: Ask one of the subject matter experts
to walk through the problem step-by-step. How do they tackle this?
What steps do they take and what tasks do they perform? Have the
rest of the team write these down on sticky notes and place them
on the wall in logical order.
 Everyone writes: Alternatively, if you have multiple SMEs or the
team is very familiar with the user journey, everyone can write down
the steps that need to be taken and put them up on the board,
getting rid of or combining any duplicates.

At the end of this, you’ll have a bunch of steps posted left to right,
taking your customer from the start to end of their journey. Take a
second to step back and think about narrative flow. Your user map
tells a story. But some users might do things differently or in a
different order. That’s fine. A story map isn’t a step-by-step guide,
but a guide for conversation and planning. Think about the ideal
user flow, but know and discuss all the different use cases as they
come up.
What if you’re working with an existing backlog? If you have a
backlog full of well-written user stories (See notes above!) you can
simply print them off and pull them into your map. In some cases,
this might even be the majority of your steps.
Step 3: Identify and group activities
As you look through the steps your user takes, you’ll start to notice
some common themes. Many of these steps are probably working
towards a common goal. In user story mapping, we call
these activities.
So, in our vacation home example, you might group together steps
like “Click sign up”, “enter personal information”, “get confirmation
email”, and “open profile”. All these steps are part of the activity of
“Account sign up.”
Your activities are listed above the user steps to make up your
backbone.
You might also realize that some of your steps aren’t actually steps.
You want to think about your map both horizontally and vertically.
This is a visual tool and where you place actions determines the
overall flow.

 If you have groups of tasks that could be done at different times (for
example, at this point, I could do X, Y, or Z), you would organize
those vertically in a column as a set of tasks or options.
 If you have a group of tasks that are done together (for example, I’d
do A then B then C), those are user steps that are most likely going
to be placed horizontally.

Step 4: Break large tasks into subtasks

It’s time to go a step deeper. The steps in your backbone are most
likely too big to be tackled in one sprint. So it’s time to break those
down into smaller tasks and user stories.
At this point, you’ll add cards, split them into two, rewrite and
reorganize them. Tasks are placed underneath their associated
step and activity to make it clear what goal each one supports.
Here are a couple suggestions of how to keep your group moving
forward from the father of user story mapping, Jeff Patton:

 Play “wouldn’t it be cool if…”: Use “blue sky thinking” and go crazy.
Don’t let anyone shoot down ideas, no matter how big they are.
 Look for variations: What else could your users do at this point? Are
there recurring tasks that you need to include? Don’t get stuck in a
single lane.
 Look for exceptions: What could go wrong and what would a user
logically do to try and recover? Look for as many potential issues as
possible.
 Consider other users: What would a different user do at this point?
Being user-centric means thinking about all your users.
 Add in other product details: Think about UI elements, data
elements, business requirements.

Don’t worry about getting too crazy or writing down ideas that are
out of scope. You’ll go through the process of taking them out of
scope later on.

Step 5: Fill in the blanks

Before you move on, you want to look for any missing tasks on your
map. One great way to test for gaps is to have someone walk
through the scenario or from a different perspective (i.e. a different
user persona). While they’re walking through it, have the rest of the
team note any situations where you’re missing a step or where their
behavior flow is different from what you have and put it up on the
board.
It’s also good to get people from different parts of your company to
go through this exercise. A UX designer might tell you where you’re
missing steps in the customer journey, while a developer might tell
you where a task is too big and needs to be broken down or too
risky to implement.
This is also an opportunity to mark pain points or problems in your
overall system. Someone walking through might say “this is an
issue” where you hadn’t thought of it.
A user story map helps you see how things are now so you can
create a better future.

Step 6: Prioritize tasks and subtasks (but leave your

backbone as is)
Your backbone tells the story of how your users move through your
product. They’re all pretty much equally important as each step is
necessary to move to the next one. The tasks that support them,
however, aren’t.
Under each section, you can prioritize the importance of tasks by
moving them up and done. Keep high-priority ones at the top and
move ones that are less important lower down.
One suggestion is to split the map vertically into different sections,
such as “Could”, “Should”, and “Must”. This way you can quickly see
the tasks that are most important for supporting your core features.
Again, this is just a suggestion. How you organize your map will
depend on your team and your product. Use the map as an
opportunity to discuss flows and organization. The right answer is
whatever works best for you.

Step 7: “Slice” groups of tasks into iterations

By now, you should have this massive beast of a user story. There’s
your backbone on top full of user steps grouped by activities, and
then a prioritized list of tasks “hanging” underneath. As you move
through your map horizontally from left to right you get a full “slice”
of what your product could do. Or, in other words, an iteration.
Now that you have the user map prioritized vertically, you can create
horizontal “slices” that represent a holistic release. If you’ve
prioritized properly, each slice should be a minimum viable product
release, creating value across each user and activity.
This will probably look a little goofy with lines curving and bending
to fit some features and not others, but that’s okay.
For each of these slices, name the target outcome and
impact. What do you hope to accomplish with this release and how
does it help contribute to the overall goal that motivates your
company?
You should also identify success metrics. For each slice, ask “what
would we measure to determine that this is successful?” Ideally,
your iterations will promote different user behaviors that you can
track and test.

How to turn your user story map into a

development strategy
Each slice of your user story map gives you a goal and a list of tasks
to get there. But with most products, you won’t be able to build
everything listed in a slice in a single sprint.
As you transition from your user story map to sprint planning, one
easy way to do this is to vertically slice your map into delivery
phases. Because your map is shown logically from left to right,
starting with a group of activities on one end and moving across
ensures you won’t hit any dependencies or roadblocks.
Use that block of tasks to plan sprints and move them into your
project management tool (like Planio). To build the ultimate version
of your software, you’ll simply move left to right through
development phases and then drop down into the next grouping of
tasks.
Your user story map takes you where you (and your users) want to
go
Whether you’re lost or just need to reassure that you’re on the right
path, user story mapping is a powerful tool. At the end of this
session you will have:

 A visual tool showing your user’s journey in sequential order (to help
see dependencies, gaps, and opportunities)
 A prioritized list of tasks grouped into iterations that represent the
minimum amount of features needed to provide value to your users
 A clear development plan that can be used for sprint planning
As a final note, remember to keep your story map updated. Like any
planning tool, a user story map is outdated the second you walk out
of the room. Keep it updated and relevant. Add in new information
or users and mark off what’s been done and continue to use it. Just
imagine walking into a sprint review with your map,
showing stakeholders where progress has been made and marked
complete.