A Guide to User Story Mapping for Agile Teams

Story mapping is a simple yet powerful technique to visualise the product backlog and view the evolution of the product as it is developed. I have used it with my teams to ensure there is clarity and alignment on priorities and scope.

The most important aspect for me is that a story map allows the team to look at the product from the perspective of the end user. It gives a holistic view of what a user would and would not be able to do with each product increment. It can often help the Product Owner with making decisions about whether to continue enhancing a particular feature or use the available capacity of the team to add additional features.

Story mapping technique is inspired by Jeff Patton's book User Story Mapping: Discover the Whole Story, Build the Right.

In this post, I’ll provide a format for a running story mapping workshop with your team.

Objective of the session

The objective of the session is to visualise the product backlog listing all features and user stories required to deliver value to the customers.

This workshop can be run at the start of an initiative or at any stage during product development. If product development is already in progress then the team should have bulk of the content from what they have done so far. The idea is to visualise it in order to validate everything has been covered and identify any missing pieces. 

Product Vision

Ensure vision of the product is well understood. This may sound obvious but it is surprising how often something as simple as this is not fully understood by everyone in the team.

Ask someone to define the vision of the product. It is important to ensure the vision of the product is articulated correctly and succinctly. By correctly I mean, it is aligned to the organisation’s stated purpose/vision of the product. It is even more important that everyone on the team is aligned with the stated vision.

Top Level Themes and Features

With the vision in mind, list all top level themes and features required to deliver the vision. Ask the team for their input and write each item on a card or a post-it note.

Once the list is stable, ensure everyone is in agreement on the top level themes and features. Check if there is a need to sequence the features based on technical dependencies. If so, ask the team to sequence the features.

User Stories

Take each feature at a time and create user stories required to deliver it.  Ask the team to think about all the user stories required to deliver the first feature. Ask them to work on their own initially and write each item on a separate card or post-it. Repeat this for all features.

Ask each team member to take turns to present their card and pin it to the board. Now ask the team to remove any duplicates.

Next step is to sequence all user stories for a particular feature based on technical dependencies. Clearly mark any dependencies on the card. This will allow the Product Owner to make informed decisions about prioritising the backlog based on business needs while taking into account any technical dependencies.

Repeat the process for all identified features.

Check with the team that everything required for successful delivery to customers including infrastructure, non-functional requirements (NFRs) etc. are included in the story map.

Group User stories by Themes and Features

Following the steps above, group the themes, features and user stories together to form a grid as shown below:

Create the Plan

Once the stories are organised, start the process to allocate stories to sprints or releases. This needs to account for estimation of work items and team capacity. We won’t go into details of how to do that in this article and assume that the relevant information is available to the team. If this information is not available then it would make sense to pause here, estimate the work before moving to the next step.

A version of the plan based on prioritisation, technical dependencies, estimates and capacity is shown below:

Output of the Session

Output of the session is a visual representation of the product backlog containing all known work items required to deliver the vision of the product. This backlog contains prioritised features and associated user stories, which can be used to make informed decisions about the product. 

The workshop would conclude at this stage. 

First Contact

Product backlog and therefore a story map is a live artefact and it’s important to ensure it’s kept up-to-date as the team progresses through developing product increments.

Update the story map following the completion of each sprint as shown below:

Updating after each sprint provides an up-to-date picture of the status of the product. This helps ensure clarity and alignment on priorities and scope delivery.

Note: I have run this workshop in-person using post-it notes and a wall/whiteboard as well as online whiteboards, such as Miro for remote teams. In any case, it's important to create and maintain the story map in an accessible location for the team.