User stories are great in that they allow people from all different parts of your organization to engage with them. However, Product Managers (PMs) have to deal with a great number of potential user stories. Many PMs struggle with the complexity of having so many user stories in Jira.
The best PMs are able to engage in structured discussions that range across many user stories and thus manage to link feature outputs with customer outcomes. They often do this using some version of user story mapping, a method described in the book by Jeff Patton, a method that works really well. In this article we will deepdive into what user story mapping is by looking at how to do it and when to do it, as well as benefits, pitfalls, and what tool stack to use.
How to do user story mapping
Combine the user stories into a map
The idea with user story mapping is to be able to have a conversation across several user stories. Generally, the approach is to visually place the user stories so that they tell a bigger story together, still from a user standpoint.
Specifically, a couple of new concepts are introduced. There is some variation in what exact terms are used, but for a simple user story map the concepts are as follows. The bigger story that the user stories tell together is referred to as an epic or a feature. This bigger story is divided into several steps, where several user stories could happen at each step. Together, the steps are referred to as the narrative backbone and form the columns of the user story map. Lines drawn horizontally represent different releases.
User story map example
To make these concepts a bit clearer, let's look at a simple example were they are all represented:
Map only the steps needed to tell the story you work on
The example user story map from the last section told the story of a single feature, i.e. that was its scope. User story maps can also be used at different scope levels.
Early on in the life of a product, one map can cover the whole product. For such user story maps, that cover a more complex bigger story, it is common to add structure to the narrative backbone, e.g. by grouping the steps by type of user.
Later on, that total map becomes rather large. Then it is perfectly fine to narrow the scope. You only need to extend the map with the steps you need to tell a compelling story around the level you are currently working. The scope we see most is that of a single feature. For those maps, it is enough to include the steps taken within that feature, and maybe some step before/after.
Tell the smallest combined story that results in the desired customer outcome
The genius with user story mapping is that by telling a coherent story from the customer's perspective for a release, you can use that as a test for whether the user stories included in the release will help the customer reach the desired outcome.
As you could see in the user story map example, the user stories are not only divided into columns depending on what step they help, they are also divided into rows based on what release they are to be included in.
This allows you to work with slicing the user stories into different releases.
Involve team and stakeholders in user story mapping sessions
The reason for doing a joint user story mapping session is to be able to work together in prioritizing customer outcomes. By talking about the user stories along a narrative backbone (i.e. the steps of a user story map) seen from the perspective of the users, it becomes easier to be customer-centric.
By bringing in the different parts of the team and stakeholders, that customer-centricity can live throughout the development of the feature. Ideally, everybody that will be working with a feature should be in the session. At the very least, all different functions of your organization that will be involved should be represented (e.g., sales/support, design, development, QA).
Going into the session, you should have a hypothesis for the narrative backbone. It is also good to have an idea of some user stories to include, but it is good to keep them in your back pocket, at least initially, to let everybody else get going on the problem. And, as we described in the first chapter, the more context you bring with you, the better (research, customer feedback, data, etc.).
Although there is almost always some iteration back-and-forth, the main steps of the session are to:
The end-product of the session is a user story map for the feature, with quite a few user stories across the steps, divided into several releases, with agreement on at least the first release to go for. Beyond that there is hopefully quite a lot of notes from the discussion.
When to do user story mapping
What development efforts to do story mapping for
Not all development efforts make sense to story map. There are some good indications to look for:
Where story mapping fits in the product management process
Looking across the product management process, it is clear that user story mapping is a refinement practice.
This means that before you do it, you should have done at least some work on both definition (working with a Product Requirements Document) of the feature and discovery of both the problem and the solution (working with an Opportunity Solution Tree). You need a clear hypothesis as a starting point to have an effective user story mapping session.
Build your Opportunity Solution Tree in Delibr!
Let us help you!
Book intro meetingPRD, story map, decisions & Jira issues in 1 epic doc
Manage your user stories in Delibr, integrate directly with Jira
Put your user stories on a story map
Check out Delibr's best practice epic template
Epic kanban board: a powerful overview of your epics
Level up your PM skills
Benefits of doing user story mapping
The benefit of story mapping is, in a nutshell: better slicing. That is better ability to find the valuable, small, coherent and agreed iterations of a feature.
By taking the perspective of a story from a user, the discussion is focused on what is valuable for the user, or also referred to as customer outcomes. By also involving the developers and contrasting the value of these stories with how much time it would take to fulfill each story, the feature output, it becomes possible to select the stories that brings the most bang for the buck. This can be expressed as maximizing customer outcomes / feature output.
By splitting stories into smaller stories, requiring less developer effort, it becomes possible to be quite granular in the discussion of what to build. By being granular in the work to maximize outcomes / output often means the parts that require effort can be excluded while still keeping the parts that create value. This also makes it possible to do smaller iterations in general, which allows the team to move faster towards creating value. The very smallest iteration that fulfills the job to be done, but barely, is sometimes referred to as a skeleton that can walk, or the MVP (minimum viable product). And the smallest iteration that can really be appreciated by users is sometimes referred to as the MLP (minimum loveable product).
By bringing together a broad set of competencies to think about stories from a user perspective PMs can both achieve better alignment and capture potential issues before the unfold. By bringing everyone in early, the PM can ensure that people are onboard later on. By scrutinizing the resulting story together from different angles there is a better chance of capturing risks & dependencies. Together, this lowers the risk of having to tear things up at a later stage to do expensive rework.
Pitfalls of user story mapping
The pitfalls with user story mapping can be categorized across the definition, refinement, and development steps of the product management process.
⚠️ Not linking solution to outcomes and opportunities
It is tempting to believe that working with actual user stories is enough to make sure that what you develop will have a great outcome / output ratio. But it is possible that you solve a problem that exists, but is not that important to users, and that does not drive your business goals. To get this right, it is helpful to work with Opportunity Solution Trees as a complement to User Story Maps.
⚠️ Not validating the solution's most risky assumptions
Another trap that could prevent you from producing a great outcome / output ratio even if you use a User Story Map is that there may be critical but faulty assumptions. To avoid this it is crucial to take another look at the feature implied by the chosen slice of the user story map, and think through and map the most risky assumptions, and then validate them.
⚠️ Not preparing enough to create context
In some ways, a user story mapping session is like any other workshop - without proper preparation and context it will be much less effective. Before going into the session it is valuable to have collected and structured the already existing thinking and input. There should be something like a first draft for a Product Requirements Document (PRD), covering topics like link to OKRs, underlying customer pain points, customer feedback, supporting data, and initial thinking on what the solution could be, etc. Here it is helpful to work off a PRD template.
⚠️ Not connecting the definition with later work
When going into the story mapping session, one pitfall is to think that the user story map will completely replace the PRD as the main reference to use when continuing work on the feature. That is a mistake, as there are things covered in the PRD that a user story map doesn't cover, like high-level rationale, dependencies, and rollout plan. Losing the thinking done on such topics risks not getting the feature right.
⚠️ Not involving the right people
The whole point of doing a story mapping session is to figure out the best way to slice a feature, the version of the solution that practically works and gets the most user value for the least developer effort.
For that to work, all the knowledge about what is valuable to users, what practically works, and what drives developer effort needs to be present. The pitfall here is to think you can get away from actually pulling the right people into the room and doing the full session with everybody involved all the way. PMs need to pull in the right team and stakeholder participants, typically this means some combination of designer, developer, marketing, sales/success, and maybe operations/IT/legal or similar.
⚠️ Not having the mindset of user stories
The magic of user stories is creating common ground across business, design, and engineering. Everyone can relate to new functionality when formulated as a story from a user. The pitfall is that different participants will pull hard, trying to reframe functionality in a format that is more comfortable for them. Designers want to talk about designs. Engineers want to talk about development tasks. Business stakeholders typically pull in roughly the right direction, but e.g. marketing can veer towards vague slogan and support can become too specific in wanting to respond to a single customer request. It is up to the PM to kindly but firmly bring people back to talking about user stories.
⚠️ Not capturing details about individual user stories
If on pitfall is losing the user story perspective, another pitfall is sticking too closely to only the user story itself, limiting the discussion on implications of user stories, on e.g. what concrete user requests it would fix, what designs could work, and what the technical implications could be. These discussion are crucial, they just need to be closely tied to user stories. The 3Cs (Card, Conversation, Confirmation) is a great framework for this, and the pitfall here is being too shallow, limiting the discussion to only the Card, and not capturing the Conversation and the Confirmation (i.e. the agreed acceptance criteria).
⚠️ Not keeping the story map for later reference
The user story mapping session needs to be visual and free-flowing. This leads many PMs to the pitfall of seeing the mapping session as a one-off, typically by either doing it on a physical whiteboard that then gets erased or by doing it on a virtual whiteboard, but not properly referring to it, meaning that it too in practice gets lost. That makes it harder to come back and reuse the thinking from the story mapping when doing the next iteration, especially if time has elapsed between the first and the second slice, which can often be the case.
⚠️ Not connecting the story map with later work
Another and more immediate pitfall that PMs fall into is rewriting all user stories from the map and the details about them into the issue tracking system. This is both unnecessary rework and creates yet another layer of redundancy, where potentially conflicting information can occur if changes happen later on. It is better if this can be done with references rather than placing information in a new place, which can be done with proper tooling.
The proper tool stack for user story mapping
As user story mapping is such an important practice, it is worthwhile investing in the right tool stack for the job.
Goals with tooling to support user story mapping
1. Enabling collaborative user story mapping sessions
Doing user story mapping in a normal document editor does not work. As you need to have a fast flowing discussion, you need to use a tool that can handle that, e.g. a physical whiteboard, a virtual whiteboard tool, or a tool with a tailor-made feature for user story mapping.
2. Smooth flow across story map and individual user stories
Referring back to the 3Cs framework, the Card is the name of the user story, the Conversation is everything that goes into discussing the user story, e.g. writing, decisions, and wireframes/designs, and the Confirmation is the agreed way to come back to determine whether the user story has been fulfilled, e.g. acceptance criteria and reference designs. Any setup needs to have a good flow for working both with the "cards" that are the user stories visible on the story map, and any details on each user story. In a fully physical setting in a room with a physical whiteboard, such details are typically captured on A4 papers that are placed on the wall next to the story map. This is a workable but somewhat quirky solution, as the links between user stories and further details are not as clear.
3. Smooth flow across PRD, story map, and Jira issues
Two of the described pitfalls relate to issues with connecting the different artefacts being used:
One goal for any tool stack to use should be to connect these artefacts, with references across, thereby removing redundancy, work to update across, and risk of missing something and having to do rework.
User story mapping tool stack examples
What tool stack to use to do user story mapping well?
Generic bolted-together tool stack, e.g. Confluence + Miro + Jira.
This is a common type of tool stack we have seen many times, including with replacement of different similar tools. Confluence for PRDs (or e.g. Google Docs or Notion), Miro for the user story map (or e.g. Mural), and Jira as issue tracker. It has a clear rationale, but also some disadvantages.
Story map collaboration is enabled by introducing Miro to the mix. For the user story mapping itself, Miro is great! It is easy to work together on a visual representation of the story map. However, without Miro in this tool stack, collaboration works much less well.
Miro is great for working on what you can see, but whenever you want to deep-dive into individual user stories, the flow becomes less smooth. Adding lots of written or visual information to postits doesn't match the whiteboard analogy. What typically ends up happening is that either notes are not/barely taken, or notes are written but detached from the story map, making it hard to know what user story they refer to later.
By introducing Miro, one more level of redundancy is introduced. This means copy-pasting and updating across PRD in Confluence, user story map in Miro, and individual user stories in Jira. This lack of a single-source-of-truth leads to both extra work and to a lack of transparency on what the latest info is, leading to confusion and risk of re-work.
Tailor-made product management tool stack, i.e. Delibr + Jira.
This is a tool stack that is tailor made for PMs and that becoming more and more common. If you want to level up your work with user story mapping, you should try Delibr. It requires teams to be more proactive and deliberate about the tools they use, but has distinct advantages.
Sweet tailor made user story map feature, where it is easy to craft the narrative backbone, slice into releases, add, and move around user stories, collaborating in real-time.
Smooth flow across story map and individual user story levels, where it is natural to deepdive to discuss each story as much as needed, and where it is then seamless to split and merge user stories along with any content on them with simple drag-drop or keyboard shortcuts (no more cumbersome cut and paste across different windows when re-slicing user stories).
No redundancy with the rest of your process, as the user story map lives within your PRD and populates it with content as you discuss individual stories, and where user stories with content can be seamlessly sent to Jira with 2-way real-time sync. PRD, story map, and user story details in one place.
Learn more about how to work with user story mapping in Delibr (and by the way, if you liked the structure above for evaluating options with pros and cons, check out Delibr's functionality for decision-making).
.png)
