Traditional product backlogs can get confusing. They typically start off with a high-level list of features, called “epics”. However, as the team starts decomposing the epics during refinement down to sprintable user stories, it’s easy to “lose the plot” and the only person with the decoder ring is the Product Owner (PO). The PO is the only one who knows how all the stories tie back up to the feature and how they relate to each other. One resulting failure pattern is incremental deliveries that create poor user experiences. This is because the release was composed of stories that in principle were of high business value but were functionally dependent on stories that were of lower value and were therefore deferred to future releases.
To the Rescue: Story Maps
The challenge presented by traditional backlogs is they are flat and do not convey any notion of the end user’s journey (See the “Outside View” column in the graphic above.) This makes it difficult to recognize if any gaps exist. Also, we can easily lose business context when trying to prioritize many user stories against each other.
Story Maps were invented by Jeff Patton [his book can be found here] to help overcome those challenges. Patton’s process helps teams discover requirements from a user experience point of view. Creating a Story Map is a collaborative exercise that incorporates the needs of the end users, the stakeholders, and the wisdom of the team, the makers. This helps transform the approach from product requirements delivery to user requirements discovery.
How To Approach Creating The Initial Story Map
There are a couple of different approaches we use when building user story maps:
1) Tell a story: Ask one of the stakeholders, or a representative such as a Subject Matter Expert (SME) to walk through from start to finish all the activities and tasks the end user would perform (the problem the team wants to solve) by telling a story. As they are describing the customer journey, multiple people (e.g., the Dev team) armed with post-it notes (digital or IRL) write down each task and place it on the wall (again, virtual or IRL). The tasks are placed roughly in time order from left to right, but not everything needs to be perfectly linear. Below is an example for an e-commerce site. (BTW, both Mural and Miro have some nice templates for User Story Mapping).
2) Everyone writes: This approach works well when you have multiple SME’s. Everyone independently writes out the tasks they would need to do and then collectively they combine them into a single map by removing duplicates.
Creating The Story Map
Once the team has an initial pass of the activities and tasks, they add a bit of organization to the map.
Group into activities: Once the initial story map has been constructed, the team then identifies groupings and defines those as activities. For example, if the user could do X or Y or Z, then those will be organized in a column as a set of options. Alternatively, if the user would do A then B then C as different discrete things, then these are placed horizontally.
Test for gaps: Next, the entire group will look for missing tasks on the map. They can do this by having someone walk through another scenario or from a different perspective (e.g. A different end user persona). While that person is walking through this other scenario another person follows along pointing at the story map to confirm things are already covered. If they hear something that is missing then they or other members of the team capture the new task via a post-it. This allows the team to flesh out any missing pieces.
Prioritize: Next the team reviews the story map and prioritizes the tasks. Within activities/columns, they move items up that are most important and items lower that are not as important. They can order within an activity and can also create different swim lanes across the story map for different levels of priority (e.g. Must, Should, Could).
Define Iterations: Now that the team has the map prioritized they can outline iterations or releases of the story map. They can draw a line for Release 1. From there they can estimate the work and refine the scope of the release as needed.
Keeping the User Story Map Alive: Story maps are not only powerful for capturing requirements for a full user journey, but also for continual visibility. Imagine showing up to the first Sprint Review and bringing in the user story map with items marked as complete to communicate progress. Wouldn’t the stakeholders who were involved in the initial map have a better understanding of progress, rather than telling them you have finished 20 of 100 points on the backlog?
Take a Deeper Dive into User Story Mapping
We cover user story mapping in-depth during our Certified Scrum Product Owner (CSPO) class. Check it out. The CSPO class is offered as a public workshop or in a private setting.
Also, read the next installment of this series, Story Mapping 201, where we discuss how to transform an inherited backlog of user stories into a story map to avoid half-baked incremental releases.
The Origins of User Story Mapping
- 2005: without giving it that name, Jeff Patton formulated the concepts of story mapping in “It’s All in How You Slice It”
- 2008: the story mapping practice was described and abundantly illustrated in Jeff Patton’s “The new user story backlog is a map”
- User Story Mapping: A better way to work with Agile User Stories
Books / Podcasts
- Jeff Patton: User Story Mapping: Discover the Whole Story, Build the Right Product
- Jeff Gothelf: Lean UX Sense & Respond and more…
- How to Design, Build & Ship Successful Products with Jeff Patton and Jeff Gothel
What’s Your Organizational Agility Score?
In less than an hour, you’ll get valuable insights into your organization so you can improve team performance and achieve your business goals faster.
