Jory MacKay on January 14, 2019 A Guide to User Story Mapping: Templates and Examples (How to Map User Stories)
🎁 Bonus Material: Free Template & Cards
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?
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 they get a fluid experience.
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:
- Domain experts, testers, and UX designers: People familiar with users and functionality
- Stakeholders: People with an idea of how the software will earn your company money
- 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 (download & print our template 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:
- Sign up for an account
- Search for vacation homes by city/price/location/availability
- View the home profile page
- Enter payment information
- Book home
- 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.
