The User Story Map
February 7, 2024
Do you like sitting in meetings all day? Do you enjoy staring at your teammates' disinterested expressions in Google Meet for hours, listening to one person monologue until your eyes start to water?
How about watching a cursor blink endlessly on a JIRA task, while you slowly black out to the faint "womp womp womp, wah wah wamp" of your teammates debating story points?
If all that sounds like a great day to you, then you probably don't need a user story map.
But if you want to avoid these soul-draining situations at all costs, and want to spend more time building clarity on a new product or feature launch with your teammates, then stick around.
There is a better way to make sure you build the right thing. There is a better way to plan your product releases. The User Story Map is your answer.
A better way
Maybe you've worked on a project before that begins something like this:
Your product team gets the green light to build a new product or feature
You begin to think about what it might entail, but you don't have many details
You have a basic (but vague) product name and somewhat clear requirements, but you're not an expert in the problem space yet.
You still need some time to dig into the core problem, talk to customers, etc.
You and the PM start researching for the project while the rest of your development team continues to ship a different feature.
At this point, I recommend focusing your team's effort on creating a user story map. It takes a few hours to start, and then the PM and UX can continue to refine it. Without one, you'll waste more time debating v1 scope than it takes to create the user story map. The time spent making a user story map is not wasted—it only helps build team buy-in and understanding.
Signals you might need a user story map
If these things are happening on your team project, they should signal you that it's time to create a user story map and help bring the team together:
Spending way too long refining JIRA tasks by staring at a blinking cursor
Endlessly debating one idea vs. another and why it should/should not be in the MVP scope
Debating the details of a specific task without understanding how it fits in the overall product
Over-designing something that never gets built because the MVP gets trimmed down so much, which feels bad
It's probably never too early to create a user story map, because they can always be refined. When I've seen them work well, we'd already done a little bit of basic research and discovery work. This might be a survey, qualitative interviews, stakeholder meetings, or some combination of all three.
The best time to start a user story map is when you have a general idea of what problem to solve, but you haven't got a full understanding. It's still hard to communicate concisely what exactly you're building and how it will work at launch. Now it's time to turn it into a clear plan.
You might be working in parallel with your PM before you have clear outcomes to aim your design at. They might give you some loose ideas resembling outcomes that aren't specific. You might get a vague a task like "build a prototype".
But what should be in the prototype? Where do you draw the line? How much time should you take to build the prototype? Is whatever you design what you should build? Where are the boundaries??
Constraints are the key to simplicity, and a user story map can help clarify those constraints.
To increase the chances of building the right thing, you need two things:
A 1-pager
A User Story Map
Lean into collaborating with your Product Manager to pinpoint the outcomes you want for your users and the business. That's where the 1-Pager can help create a north star. That's your "why". The User Story Map is the "what" and "how".
What is a user story map?
A user story map has 4 main parts:
[image of annotated user story map]
A context or problem space with a beginning and end
A set of high level tasks a user must complete to solve their problem
A set of low level tasks that comprise the high level task
One or more lines indicating each release, which separates low level tasks into buckets of work
When you've set up a user story map correctly, every high level task should be a necessary step in solving the user problem. Reading from left to right, you can travel through the user experience to see what steps a user could take in release 1, 2, and beyond, and start to visualize the experience at the highest, least defined resolution.
Low level tasks
Think of these like user stories. They usually end up translating into a single JIRA task or user story for your backlog. Make as many as you like, but make sure that each has a "so what" attached to it.
Why is a User Story Map helpful?
One of the hardest parts about building software as a team is that everyone has a slightly different vision of what is necessary, what the end result should look like, and what is important to do first.
A user story map allows everyone on the team to contribute all of their own ideas in a way that is approachable and simple enough for anyone to understand. You don't need to know all the JIRA faux pas to avoid when you just put a sticky up in plain English.
Once all the ideas that are slightly different in anyone's mind are laid out there, prioritization becomes a logical exercise, where you can reason out in a coherent discussion why a certain feature is valuable, but not necessary for the first release.
When people can understand that their ideas are valuable, but maybe not the best thing to tackle first (because the top priorities are clearly laid out in front of them), it boosts morale and collaboration. People feel acknowledged for bringing their idea to the table, and it's clear where their highest contribution can fit into the team vision right away. People aren't swatted down for suggesting something at the wrong time, when a PM is trying to reduce scope.
User story maps help PM scoping decisions become clear and reasonable, rather than a black box for the uninformed. This is critical for team morale on agile teams that typically work in such short sprints that it's hard to see the forest for the trees.
How to create a User Story Map
You can use a whiteboard, stickies, or a digital tool. Or a piece of paper! But something that allows you to re-sort the low level tasks quickly will come in handy when indicating your releases.
You need to have a good understanding of your user problem and goal. The cool thing about a user story map is that you can start with a pretty rough understanding of the problem, and over time you will refine the problem more and more. You might start with 2 or 3 simple high-level steps that you can start to break down.
Before you know it, your team will have a solid grasp of the problems you're going to solve. And all that's left is breaking those pieces down into even more manageable chunks.
This is a highly accessible exercise for any member of the product team--not just the UX and PM. In fact, it can really build team ownership to fill out the User Story Map together, so that everyone gets their own ideas on the map. That will build out the backlog even more than it might be if it's just the PM and UX making up the goals and activities.
Tools
Digital
Miro
Analog
A wall with post it notes
Sharpies
Best practices
Use your best judgment to make each release actually viable to users. They should typically solve the problem "end to end", and not leave a complete step out of the release. Polish should be ruthlessly deprioritized to releases beyond the MVP.
Conclusion
You should use user story maps. Every minute spent building it brings your team closer together, builds a shared understanding, and generates a ton of momentum towards the MVP that can carry your team to v2 and beyond.
tl;dr - User Story Maps generate clarity, buy-in, and bring people together. And those people build better products, have more fun working together, and find delight in the otherwise missed opportunities that low morale causes one to miss.
