User Story Mapping - Build Better Backlogs
User Story Mapping is an exercise to drive and organize a Product Backlog into a User Story Map. In this post I describe the structure of a Story Map and how to create one.
Photo by Capturing the human heart. on Unsplash
What is User Story Mapping
Note: This post contains affiliate links
User Story Mapping is a technique to help Product Owners (and anyone interested in a product under development) organize and understand the Product Backlog. A Story Map describes a series of activities and supporting tasks that a specific type of user (persona) engages in to achieve a goal. It drives the Product Backlog, which is a prioritized list of all the features (User Stories) that are planned to be delivered in the project. Items in a Product Backlog may or may not be related to each other, dependent on one another, or for the same type of user. When the backlog gets large it is difficult to work with or even comprehend. A Product Owner needs to understand and defend the presence of all stories in the backlog. The Story map creates a hierarchical structure that connects all User Stories back to user activities and goals.
User Story Map Structure
A User Story Map is structured as follows:
The image above is an example of a User Story Map for a Social Media Platform. There is a persona identified called the Social Media User. Moving from left to right from the persona are a number of high level Activities that form the Backbone. The backbone runs across the entire User Story Map. The distinct tasks that make up the Activities are placed directly below the Activities. The tasks spur the creation of User Stories or features that enable the completion of the tasks.
How to Create a Story Map
I highly recommend reading Jeff Patton’s book, User Story Mapping. I have attempted to distill enough of Jeff’s book to get you started, but this post is no replacement for the depth and understanding you will get by going directly to the source of the Story Mapping approach.
The audience is the key driver to the Story Map and the natural starting point. The audience is described as user personas. Invest some time in understanding and defining who you are serving with your solution. What problems are they trying to solve? What are their goals and motivations?
Choose a persona and write it on a post-it note (sticky). Select a special colour for that sticky and only use that colour for personas. The persona goes in the top left corner. If there are multiple personas you may need multiple Story Maps for those personas.
To the right of the persona are the high level activities. These are the sea level tasks. The tasks that your persona performs in a single sitting. Some examples of sea level tasks include:
- Writing an email
- Creating a system account
- Reading an article
- Posting a social media update
These are biggest things you would start and complete without interruption, they stand on their own and achieve a micro-goal.
The Backbone shows the breadth of the backlog. When creating a new User Story Map for a persona don’t drill down into the activity details; instead think breadth first. User Story Mapping encourages building features to hit minimal viability across all the user activities of a product. We are slicing horizontally, end to end, to achieve business value.
Tasks are the detail behind activities. The below sea level actions that roll up to the completion of the activity goal. There can be multiple task paths in an activity that result in its completion. For example, with the Post Social Media Update activity, I might add hash tags to my post, and I may not. I might apply a filter to my image update, or tag people in the image. These are optional tasks. They are also the tasks that find themselves in later releases. The tasks at the top are the bare essentials that every task path must include.
The tasks become User Stories and map back to the product backlog.
The real power of the User Story Map is in release planning. I have worked with many teams that attempt to deliver a project by digging way to far down into the initial activities of the user journey and leave the later activities, where the true value is finally realized, completely untouched. Jeff Patton describes this as the incremental approach, where one small part of the system is over built. Story mapping guides Product Owners and teams towards an iterative approach where a minimal set of tasks for each and all activities are satisfied in a release.
The iterative model can be a tough concept to grasp, and it seems inefficient to spread focus across many different types of activities. The story map structure helps communicate this idea.
User Story Maps vs Customer Journey Maps
You may have heard of Customer Journey Maps. User Story Maps sound very similar. In one case, they are exactly the same. When the User Story Map explains the current user experience. Now you have a journey map. The User Story Map is meant to describe the vision of the product, not a current state. However, you can use a current state journey map to elaborate into a story map. Improvements to the customer journey become the product vision and can drive your product backlog.
The User Story Map is a powerful visualization tool for creating and organizing a product backlog, prioritizing User Stories and planning releases. Its original format is as a physical whiteboard with post-it notes and tape as well as design artifacts and anything else that helps tell the story of the product.
Story maps start from the user persona perspective and detail the activities this person engages in to achieve goals with the product. The user activities form the backbone of the story map. Once activities are identified, the individual tasks that are part of completing the activity are added below and become the User Stories in the backlog. Releases slice through these tasks and help the Product owner prioritize and build the product in an iteratively.
“User Story Mapping - Discover the Whole Story, Build the Right Product”, Jeff Patton, O’Reilly Media Inc., 2014