User Story Mapping - An essential planning technique for Product Managers
by Chris Petersen
Some of my fondest memories as a PM involve spirited conversations with my team, hashing through a large chunk of work, pointing at diagrams on the wall, challenging each other, and reaching agreement on what we were about to do and why. In that room, for a brief moment, everyone has context, is aligned, and is usually pretty fired up. The challenge comes when reality hits, and work begins days or weeks after the planning meeting. The team has many artifacts including meeting notes, backlogs full of epics and stories, and high-fidelity clickable prototypes, but somehow the shared understanding that the team had in that meeting room is a little lost.
Fortunately many PMs and development teams have adopted the practice of user story mapping to act as the “glue,” and to be the reference that ties together all of the other artifacts. Those that embrace this technique will de-risk large and complicated workflows, move through development more quickly, and provide a better experience for the user at each step.
What is User Story Mapping?
In simplest terms, a user story map is a visual representation of the steps a user takes to complete a workflow to accomplish a goal. It’s not a mock-up or prototype. It’s actually the same content that would be in a traditional “flat list” style backlog, but laid out left to right as the user would progress through the workflow. You can story map an existing process as a way of visualizing customer research and use it to identify unnecessary steps and bottlenecks before you start to come up with solutions. You can also use it as a planning tool for greenfield development activities. Big process steps across the top are called “the backbone” and roughly equivalent to epics, the detailed steps a user takes are below each backbone item and are content blocks that will turn into user stories with higher priority items towards the top.
Why adopt User Story Mapping as part of planning?
Like most things, you get out of story mapping what you put into it. A PM can very actively “drive” a story mapping session while developers “watch” and miss 90% of the benefit. You get to carry the story map with you afterwards as something to reference, but a lot of the value is conversation that generates the map. The best sessions are moderated but not discretely “led,” allowing everyone in the team to create stories, move priorities, challenge, and question each other - all with the orientation of how the user will experience the workflow. It gets everyone engaged and all participants understand how stories are related to each other as well as why some are higher priorities than others.
Once the map is more or less done the team can then draw release lines or “snap lines” across the map to define multiple future releases. In addition to being a user-focused map of all the work to come, it’s also a way to efficiently break up big projects into multiple releases.
Figure 1: A user story map with release lines
About the Author
Chris Petersen is an independent product management consultant based in Boston. He spent 9 years in product management at Carbonite, leaving in early 2020 as the VP of Product Management for all SMB-focused data protection and security products. Prior to Carbonite, Chris worked in product development for telecommunications and aerospace firms on the West Coast.