User story mapping is a visual exercise that helps product managers and their development teams define the work that will create the most delightful user experience. It is used to improve teams’ understanding of their customers and to prioritize work. Software leader Jeff Patton is often credited with having developed and shared extensive knowledge around user story mapping.
In user story mapping, teams create a dynamic outline of a representative user’s interactions with the product, evaluate which steps have the most benefit for the user, and prioritize what should be built next. For agile organizations, it provides an alternative to building a flat list of backlog items or working from lengthy requirements documents.
User story mapping employs the concept of user stories — which communicate requirements from the perspective of user value — to validate and build shared understanding of the steps to create a product users love. Teams write user stories in a format that captures business value and can be completed within a development iteration (usually called a sprint).
The user story format — As a [type of user], I want to [action] so that [benefit]. — can be helpful in thinking about product interactions from a user’s perspective.
By visually mapping out these user stories, product teams tell the story of the customer journey and break it into parts. This helps them design and build functionality that is focused on desired customer outcomes, instead of solely on development output or feature specifications.
The following are some of the ways that story mapping helps teams improve their processes for building products users will love.
When a product team builds a user story map, they are envisioning the product from a user’s perspective. The resulting story map helps them identify how users experience the product and what efforts will lead to the best outcomes. This forces an outside-in approach to product roadmap planning.
Building a holistic visualization of all the work necessary to deliver a complete product experience can help teams decide what is most important, organize work into releases (the delivery of a new customer experience), and de-prioritize work that has less user value.
Many teams struggle to write strong user stories and requirements. User story mapping can help by providing a visual representation of how large items of work break down into smaller ones, and by illustrating how work items fit together.
User story mapping helps teams group their work into iterations and releases based on how valuable it will be to users. Working on the most important things first means teams can deliver the most customer value faster, get early feedback from customers, and learn quickly what product features will be most valuable.
Creating a story map of how users interact with a product can give teams a global view of the product that helps them visualize potential blocks, risks, and dependencies that must be mitigated in order to deliver the product successfully.
The process of conceiving and building a user story map gives teams a shared view of the customer experience and the work that is required to improve it. The exercise encourages conversations that lead to a shared understanding of what to build, when, and why.
User story mapping is a collaborative exercise that helps align cross-functional teams around building a product that will be better tomorrow than it is today. For this reason, any team whose work will contribute to the successful delivery of customer value should be represented.
Since a user story map creates a holistic view of the product, it is helpful to include members of any teams responsible for architecting the complete product experience. These teams are often represented in a user story mapping exercise:
User story mapping starts with a decision about what medium to use for building the story map. It can be done with simple physical resources — such as a wall or whiteboard and sticky notes — or with a variety of software tools that are available to create a virtual map. Virtual planning may be helpful for distributed teams. Regardless of the medium, teams will want to take the following steps:
User story mapping can be beneficial to teams that want to move fast and build products customers love, but it can also yield disappointing results if teams are not prepared. These are some challenges to watch out for:
If you do not know who the customer is, then it is impossible to work out how they experience the product. You must know for whom you are mapping stories.
If you do not know what problem your product is solving for customers, the entire exercise of user story mapping can backfire. Building out stories towards the wrong customer goal can result in a waste of time and resources — not just in the exercise itself, but also for the sprints and releases that are based on it.
Physical story maps made from sticky notes on a whiteboard are difficult to keep updated. The notes stop being sticky and fall off, whiteboards get cleaned and the work is lost, or iterations and releases get shipped without updates to the board. Additionally, story maps built in a single, physical location do not serve teams in other locations who cannot see them.
Stories from a user story map typically need to be recreated in a flat backlog afterwards, such as a software engineering tool, in order for development teams to begin working on them. As a result, this exercise can make teams feel that they are doing the same work twice.
At the end of a user story mapping exercise, if teams have not done so already, they will need to schedule their outline of prioritized stories into sprints and releases. The product team may want to share or review the user story map with teams that did not participate, including leadership, to ensure there is agreement on the product roadmap. Any teams contributing work to the upcoming sprint or release who were not represented in the mapping exercise will need to add their work in as well.
Product and development teams will likely transfer their user story mapping artifacts into a shared software engineering tool. Engineering teams may need to add technical specifications and acceptance criteria to ensure all the work delivers the user value identified in the story mapping exercise.
A user story map need not be static. Teams can update it with findings from research spikes, revised estimations, and user feedback from sprints and releases. The story map can also be used as a visual roadmap to communicate both the planned work and the work that remains.
Finally, teams doing user story mapping should take advantage of each exercise as an opportunity to get closer to customers and increase their levels of empathy for what the customer is trying to accomplish. Story mapping is a tool to help product managers and their teams create customer value with an incremental, iterative approach, with opportunities to learn and improve as they go.