What is User Story Mapping?

Introduction

A common challenge for many organizations is how to take the high level stated requirements from senior staff, stakeholders and users and translate them into actionable and logically ordered items. 

Even if you write a long and detailed list it can be very difficult to read, consume and check for omissions.  Many people are visual learners and so respond well to a visual picture.

In a previous article we introduced the topic of user story mapping as a key part of the product management process. This article takes a look at the topic in more detail including what user story mapping is, how to do user story mapping and why you would use it.

Why use User Story Mapping?

In traditional waterfall projects, lengthy requirements documents would be prepared, which development teams would work against until all stated sections were deemed to be met. At this point the project would move into a testing phase and then a user acceptance testing phase. Although these documents can be useful in terms of providing a large amount of information, there are some drawbacks to their inflexible and unwieldy nature.

User stories have been widely accepted as the de-facto standard for conveying requirements to development teams, but just a long list of user stories can be a bit confusing to those consuming it, both from a stakeholder perspective and from a developer perspective.  

User story maps provide an easy to view, structured, transparent and contextual view of user stories ensuring that any of the required steps for the journey have not been missed.

How to do User Story Mapping

The user story mapping process consists of the following steps

1. Identify your high level activities. This can be done by reviewing the user journey for the relevant part of the system that you want to create the map for. Activities are also known as “Goals” or “Themes”. How?:  Such journeys should be relatively clear and apparent from the high level requirements, but should be reconfirmed with the relevant stakeholders.  Once you have this list of activities you arrange them in chronological order from left to right as if you were telling the story of your user’s journey 
2. Document the steps required to complete all the necessary functionality in order to achieve the activities. These steps are often individually labelled as epics as they tend to encompass closely linked groups of user stories and tasks and are often referred to as the “backbone” of the story map, as they provide much of the structure.
3. Identify the details.  These will be the actual user stories and tasks required at a fine granular level.  These are best fleshed out in conjunction with not only the stakeholders who are asking for the functionality, but also with the team who will be building it to ensure the best solutions are designed.

Once you have the map laid out you can start identifying natural slices of the product that would be suitable as user releases. The best way of developing software involves continuous integration so that software is integrated and released in a little and often fashion, but just because the code has been merged to the code base it doesn’t mean you have to make every small change available to the user immediately.

Example User Story Map

The below image shows an example user story map covering elements of a user log in page and changing of account details for an e-commerce site.  Note that the blue boxes map to activities, the orange boxes to steps and the grey boxes more to the details of how the specific items will be achieved.

When is User Story Mapping Not Suitable?

User story mapping won’t work in every situation.  If there is no clear user journey, such as with API building work then it would be quite difficult to use. If your team was doing more operational response, such as fixing bugs or responding to user issues, then it would not be possible to create a user story map for such work.  

In a highly experimental agile environment where the next iteration’s work was highly dependent on the outcome of the experiments from the last release, such as a startup in the discovery phase, extensive user story mapping would also not be possible, although you could at least use it to plan the next increment of delivery.

Conclusion

User story mapping is a highly interactive and visual method of representing a list of stated requirements from stakeholders, senior employees and users of the system in a chronological and structured way.

It provides a highly transparent way of examining the functionality which has been identified to the build, the order in which to build it and the desired release slices that will be made available to the users.