Story Mapping 101
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.
[If you want to learn more about how to use Agile techniques to build better products, check out our guide to great Agile transformations, 8 Common Pitfalls of an Agile Transformation.]
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
Want to drive efficiency and predictability in your organization?
Our organizational assessments give you the plan to grow these capabilities and accelerate your journey to real, impactful outcomes.
11 Responses to “Story Mapping 101”
Nice! Looking forward to part 2.
Love these diagrams. Story Mapping is truly an art and not a science. This gives a really nice way for someone, (like me) who’s new to the PO role, to take the important first steps of having a conversation to start the storytelling process.
Interesting write up on Story Mapping. It appears one can easily do this using Mind Map also.
This is great, and I have used Story Mapping with many Software applications. Does anyone have any tips on how we apply this to solving problems with analytics? How we can apply Story mapping in Big data world?
start with the questions you want to answer.
[…] a great intro to story maps, check out David Hawk’s post over at Agile […]
[…] Teaser: Backlogs can be confusing. They typically start off with a high-level list of features, which we call “epics” that make sense to everyone involved. However, as we start decomposing all the way down to sprintable stories soon everyone will be lost and the only person with the decoder ring is the Product Owner. They are the only one who knows how all the sub stories tie back up and relate to each other. The challenges presented by traditional backlogs is they do not convey any notion of workflow. This makes it difficult to recognize if any gaps exist. Also, we lose business context when trying to prioritize all the smaller stories against each other. Read more… […]
The beauty of simplicity! So much knowledge in luckily not too many words.
Good work, thanks! 🙂
[…] There is a good primer on Agile Velocity for getting started with Story Mapping. […]
Story mapping a project would identify what is the flow making it easy to identify and pinpoint the possible errors if you encountered. You can easily identify the tasks of other team members and start where they left. Thank you for writing great content.
Glad you found it helpful. If you need more info on story mapping, another one of our Agile coaches, Reese Schmit, did a follow-up on how to do this mid-project.