User Story Mapping: Discover the Whole Story, Build the Right Product

by Jeff Patton

map—that left-to-right shape with the steps people take to tell a big story.

If you keep a map on the wall, you’ll find it’s good idea to add user interface (UI) sketches and other notes around the map.

The left-to-right order is what I call a narrative flow, which is an academic way of saying the order in which we’d tell the story. Of

For this big system, that narrative flow has to cut through many different users’ and systems’ stories.

Scope doesn’t creep; understanding grows.

Focus on what you hope will happen outside the system to make decisions about what’s inside the system.

Focus on outcomes—what users need to do and see when the system comes out—and slice out releases that will get you those outcomes.

Focusing on specific target outcomes is the secret to prioritizing development work.

Differentiator A feature that set them apart from their competition Spoiler A feature that is moving in on someone else’s differentiator Cost reducer A feature that reduces the organization costs Table stakes A feature necessary to compete in the marketplace

The minimum viable product is the smallest product release that successfully achieves its desired outcomes.

minimum viable solution.

The minimum viable solution is the smallest solution release that successfully achieves its desired outcomes.

What are our biggest, riskiest assumptions? Where is the uncertainty?

What could I do to learn something that would replace risks or assumptions with real information?

minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption.

Your first story discussion is for framing the opportunity.

Validate that the problems you’re solving really exist.

Sketch and prototype so you can envision your solution.

Prototype and test with users to learn whether your solution is valuable and usable.

Treat every release as an experiment and be mindful of what you want to learn.

product discovery

Map only what you need to support your conversation.

The best estimates come from developers who really understand what they’re estimating.

functional walking skeleton—a

“tracer bullet.”

unknowns.” Don’t pretend they

Great art is never finished, only abandoned. — Leonardo da Vinci

Use iterative thinking to evaluate and make changes to what you’ve already made.

Use incremental thinking to make additions.

Opening game Focus on the essential features or user steps that cross through the entire product. Focus on things that are technically challenging or risky. Skip the optional things users might do. Skip the sophisticated business rules you know you’ll need before you can release. Build just enough to see the product working end-to-end.

Midgame Fill in and round out features. Add in stuff that supports optional steps users might take. Implement those tough business rules. If you’ve done your opening game stuff right, you’ll be able to start testing the product end-to-end for things like performance, scalability, and usability. Those are all the quality concerns that are hard to bake in. We need to be aware of them, and constantly test them.

Endgame Refine your release. Make it sexier, and more efficient to use. Since you can use it now with real data and at scale, here’s where you’ll find improvement opportunities that were hard to see from a prototype. It’s here ...

next minimum viable product experiment.

User tasks are the basic building blocks of a story map.

Alistair uses an altitude metaphor where sea level is in the middle, and everything else is either above or below sea level. A sea-level task is one we’d expect to complete before intentionally stopping to do something else. Did you write “Take a shower” in your list of tasks? That’s a sea-level task because you don’t get halfway through your shower and think, Man, this shower is dragging on. I think I’ll grab a cup of coffee and finish this shower later. Alistair calls these functional-level tasks and annotates them with a little ocean wave. But I’ll just call them tasks.

Use the goal-level concept to help you aggregate small tasks or decompose large tasks.

I’ll call this left-to-right order the narrative flow, which is a fancy way of saying “storytelling order.” We’ll call this whole thing a map and that narrative flow is its left-to-right axis.

Maps are organized left-to-right using a narrative flow: the order in which you’d tell the story.

Details, alternatives, variations, and exceptions fill in the body of a map.

find there are bunches of stories that seem to

Activities aggregate tasks directed at a common goal.

Activities and high-level tasks form the backbone of a story map.

Use slices to identify all the tasks and details relevant to a specific outcome.

describe what people do. Tasks have different goal levels. Tasks in a map are arranged in a left-to-right narrative flow. The depth of a map contains variations and alternative tasks. Tasks are organized by activities across the top of the map. Activities form the backbone of the map. You can slice the map to identify the tasks you’ll need to reach a specific outcome.

Frame the problem. Who is it for, and why are we building it?

Map the big picture. Focus on breadth, not depth. Go a mile wide and an inch deep (or a kilometer wide and a centimeter deep, for my friends in the rest of the world). If you don’t have a clear solution in mind, or even if you think you do, try mapping the world as it is today, including pains and joys your users have.

Explore. Go deep and talk about other types of users and people, how else they might do things, and the kinds of things that can (and likely will) go wrong. For extra credit, sketch, prototype, test, and refin...

Slice out a release strategy. Remember: there’s always too much to build. Focus on what you’re trying to achieve for your business, and on the people your product will serve. Slice away what’s not needed to reveal minimum solutions that ...

Slice out a learning strategy. You may have identified what you think is a minimum viable solution, but remember that it’s a hypothesis until you prove otherwise. Use the map and discussion to help you find your biggest risks. Slice the map ...

place in front of a subset of your users to learn what’s real...