Enhancing product clarity: the why, how, and what of User Story Mapping

User story mapping is a frequently used technique to help organize, structure, and prioritize the product backlog along two dimensions. It visually depicts the entire backlog along the user journey while simultaneously showing the priority of user stories associated with each step in the process. User story mapping is an excellent communication aid for getting everyone on the same page and it allows for easy definition of releases. It is where you can clearly see the steps from MVP to fully fledged solution. 

The idea was originally formulated by Jeff Patton in a 2005 magazine article. Ten years later, he released the now famous book on user story mapping and – more broadly – on the misunderstood idea of user stories overall.

Having mentioned user story mapping in passing while writing about ideas for structuring the backlog, I want to go deeper today. I will explain why user story mapping is helpful and give some practical hints on how to make best use of the technique. 

First though, what is a user story map?

Email address:

Leave this field empty if you're human:

How a user story maps looks like

The picture below shows the structure of a user story map with its two dimensions. From left to right is the time dimension showing the sequence of user interactions with the product. The second dimension is valid for the user stories. They are arranged from top to bottom in decreasing importance or priority. 

The top two rows of the story map are often called the “Backbone”. In the first row are the activities, i.e. the main goals users have when interacting with the product. Using an e-commerce platform as example, the activities could be “Search for a specific product”, “Purchase a product”, or “List a product for sale”. As this example shows the time dimension isn’t necessarily valid for activities (listing a product is temporally independent from search). 

The second row in the backbone are the actual steps within the user journey associated with the activity above them. They are in sequence and the time dimension applies for this row. In the e-commerce example the steps related to the activity “Search for a specific product” could be “Enter search term in search bar”, “Browse results”, and “Apply filters”. 

Below the backbone are the user stories. Below each step of the user journey are all stories necessary to completely satisfy user needs for that specific step. They are ordered in decreasing importance or priority from top to bottom. User stories for “Enter search term in search bar” could be “Give autocomplete recommendations”, “Show recently searched terms”, or “Recommend popular products”.

The stories are assigned to different releases by introducing horizontal separators. Each release has a defined outcome. This outcome is to the left of each release and also includes how success will be measured.

That’s it. The structure seems simple enough. Let’s address why user story mapping is worth considering.

Why even attempt user story mapping?

Many feel that the linear backlog – essentially a list of user stories – is insufficient in representing the product. While it is great in showing priorities, the linear backlog doesn’t intuitively depict the product’s progression or sufficiently include the user’s goals and interactions with the product. 

The user story map on the other hand, is a visual that clearly includes the user flow and the user’s aims. The user story map thus helps in showing how each single story or tasks fits the bigger picture. 

With the inclusion of releases, the map clearly visualizes which parts of the user experience will be impacted in the product progression. It clearly shows the product development from MVP to full solution.

Overall, user story mapping offers a rich picture and thus helps in building a shared understanding. It is also a great basis for all manner of strategic product discussions. 

The process of user story mapping

The process of user story mapping isn’t overly complicated. It consists of four steps.

1. Set the stage
2. Build the Backbone
3. Fill the user stories
4. Define releases

1) Set the stage

First, you need to define the basics and answer the following questions. 

Why are you building the product?
For whom is it?
What problems are you solving?

The answers will give you and others involved in the exercise background information that helps in decision making. The answers will frame your thinking and give a goal to work towards. Additionally, they offer constraints to the theoretically unlimited solution space. 

2) Build the Backbone

Next, you will build the Backbone of the user story map. First define the activities, the high level goals users want to achieve. Then, write out the big steps the user goes through when interacting with the product. Some might call this the user journey, in the language of Teresa Torres it would be the experience map. 

It is important to validate the steps as much as possible relying on (past) user research. Additionally, it always makes sense to involve real customers or important stakeholders as much as possible, either in the process of creating the user story map or in reviewing what you created. 

3) Fill the user stories

The next step is filling in the user stories needed to fully satisfy the user needs for each step in the chain. Below the major steps simply list all user stories in descending priority. 

It makes sense to go from high level to detail. This means, you will likely start with high level stories or epics. Then you will continually refine and break them down until you have sufficiently small user stories or accompanying tasks. 

This is essentially a brainstorming step with no wrong answers. You can and will later remove things from the scope of the map. So, don’t worry about adding too many stories.

4) Define releases

Finally, you need to define the releases, starting with the MVP. The emphasis here is on the V – viable. The MVP is not the infrastructure or a click dummy. The first release needs to be something that users would pay for, a viable product. 

Defining the releases is done simply by introducing horizontal dividers, slicing the entire map into different sections. These sections are the releases in descending sequence from top to bottom. For each release you need to define target customers, the outcome you are trying to achieve, and success metrics you will measure. 

Defining the releases is also the step to evaluate which stories are really needed. This is where you will remove stories and tasks from the scope of what you want to do.

Three practical hints for improving user story mapping

Although the user story map and the process of building one seems simple and intuitive, as always the details are what define the effectiveness of the technique. To increase its usefulness, I want to share three best practices in using the story map:

• Don’t lose sight of your target (customers)
• Use the story map as a roadmap
• Don’t get caught up with semantics

Don’t lose sight of your target (customers)

The first step in the process of building the map might seem trivial or less important than the others. However, it is crucial to really define why and from whom you are building what you are building. Importantly, you need to keep this in mind and frequently double check if it is still true. 

There are always a seemingly unending stream of requests, an unlimited number of features to build. By answering the three basic questions in Set the Stage you are constraining the solution space to items that actually work towards achieving a desired outcome and/or serving target customers. 

Limiting the things to work on and saying No more often than not is so hard, but so important. The focus it brings is what really allows for rapid product improvements and sustained success.

Use the user story map as a roadmap

You can use the user story map as a shared reference to communicate to stakeholders the overall product goals, what the team is currently working on, and what the next steps are. This is exactly the same overview that a typical, time based roadmap delivers – in a different format. 

Thus, instead of creating two documents, I recommend using the user story map as the roadmap (similarly as you can do with the Opportunity Solution Tree). 

More generally speaking, you can always use it as a communication tool. There is no harm in pulling out the user story map in all reviews, retros, or other updates. It fosters  transparency and a shared understanding and thus helps in enabling effective collaboration.

Don’t get caught up with semantics

There doesn’t seem to be a real consensus on the names of the artifacts in the user story map. I have used activities, steps and user stories. Others use journeys instead of activities, epics instead of steps, or some other naming convention. 

I don’t know why, but for some reason semantics frequently seem to be a point of contention. Far too often, I have witnessed heated exchanges about naming the artifacts correctly, instead of discussions about the contents.  

Don’t waste time on these discussions. Agree – or disagree and commit – on the naming (quickly) and move on to filling the story map. The goal in product development is always to build small increments and get customer feedback as soon as possible. There is no time to waste on discussing semantics.

(Btw, a similar dynamic can arise during the release planning. Instead of making quick decisions, building first versions and learning from user feedback, some teams spend hours upon hours discussing whether the 17th subtask for a given step should be in release six or seven. Make a quick decision and move on!) 

Conclusion

Jeff Patton’s idea of the user story map is one of THE tools in guiding product development efforts. Its visual nature creates a shared understanding uniting developers, designers, stakeholders, and product people around a common table. 

User story mapping creates a full picture where anyone can – at a glance – see the main problems the product solves, the user interaction with it, and the manner in which iterations address user needs. It is a simple but powerful tool that anybody working in product development should have in their arsenal.