What is User Story Mapping?
User story mapping is a tool that allows adding a second dimension on the backlog and has been developed from Jeff Patton. User story mapping makes the workflow & the users of a system visible (if a workflow exists), allows visualizing the relationship between Epics, and provides a structure for prioritization and identifying releases.
You can use User Story Mapping on new projects, new features on existing projects or even when you want to support a conversation similar to mind map.
The benefits of using mapping over stories
- Not to lose sight of the big picture. Because user stories are describing small parts of the functionality it is easy to lose the whole picture (see the trees for the forest). In cases like this it becomes obvious that the resultant products are not well assembled.
- What exactly will be delivered. It is easy to define what will be delivered regardless the size of the product.
- Helps remember discussions over stories having the whole conversation in a single place, the map.
- To finish work within the time frame. Using acceptance criteria and slicing the map in releasable milestones.
- Define users and their stories. Because good user stories are written from the user’s perspective.
- Find holes in your thinking. When you have the complete map you can spot logical gaps.
With the map it comes naturally to create Vertical Slices. As Mike Cohn refers on User Stories Applied, there are two reasons on working with Vertical Slices.
- Exercising each layer of an application’s architecture reduces the risk of finding last minutes problems in one of the layers.
- Although not ideal, an application could conceivably be released for use with only partial functionality as long as the functionality that is included in the release slices all the way through the system.
While it seems that with user story map you need to have the complete project in a map, something that reminds more the incremental methodologies, user story mapping is as dynamic as the backlog that a team is using. It is the actual backlog transformed in a way that we can use it more efficiently.
Organize Stories in to Maps
Before starting with the map it is worth mentioning that having the User Stories as the building blocks, there are some characteristics of a good quality User Story following the INVEST mnemonic. User stories should be:
Making The Map
You can start creating the Map by writing one story at a time. Add different stories per different user or role.
Organize the Stories by adding them from left to right in a way that you will describe the flow of the application, “we will do this and then this…”. The sequence of the Stories is called Narrative Flow, which is the storytelling order. At this point it is easy to find missing details by reading the Map.
Explore alternative stories. When things are not going as planned, we should also define alternatives. This could also lead to Map reordering/reorganization of the Stories. Adding new Stories prioritized from top to bottom, taking in mind the Story’s value. In contrast to the Narrative flow, we define the alterations as “we will do this or this…”.
Group User Stories under Epics creating the backbone of the Map.
Having multiple type of users (roles) with possible different actions or User Stories can be mapped also under the User Story Mapping as shown below.
Story mapping also allows you to create Slices that can be considered Sprints, milestones or even releases and in that way can help you reach a specific outcome. Having prioritized the User Stories from left to right and from top to bottom you can easily keep the most valuable User Stories in different slices, by giving priority and implementing a complete path of functionality.
There are plenty of online tools that you can use; some of them are also free of charge. In case your backlog is not being updated often then you can also use a simple excel file and keep the mapping along with the details of each user story for example in two different tabs.
Some of the tools can be found below: