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

by Jeff Patton

Story mapping is a technique that provides the big picture that a pile of stories so often misses.

What has also been proven over the years is that, when used as a method for designing the behavior and scope of a digital product, one-feature-at-a-time yields a Frankenstein monster of a program.

By mapping out the user’s stories, the design retains its narrative structure yet can still be deconstructed for effective implementation.

We can redraw sketches or move sticky notes around, and the cool thing is that we’re really moving ideas around. What we’re really doing is evolving our shared understanding. That’s super-hard with just words alone.

At the end of the day, your job is to minimize output, and maximize outcome and impact.

Stories aren’t a written form of requirements; telling stories through collaboration with words and pictures is a mechanism that builds shared understanding. Stories aren’t the requirements; they’re discussions about solving problems for our organization, our customers, and our users that lead to agreements on what to build. Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build.

Story mapping is a pattern. It’s what sensible people do to make sense of a whole product or whole feature. It’s what they do to break down large stories into smaller ones.

That person told Gary to write down a list of all the things he wanted, prioritize the list, and then they would talk about the highest-valued things—the most important—and start building them one at a time. That list of things is what Agile processes refer to as a backlog, and it seemed to make sense to Gary to create the list and start with the most important things first.

Talk and doc: write cards or sticky notes to externalize your thinking as you tell stories.

Why are you building this? Tell me about the benefits for you and for the people who will use this. What problems does it solve for those people and for you? As you read this you might detect I’ve got that now-and-later model in my head. I’m trying to understand the outcomes Gary is looking for, not the output he wants to build.

You’ll find that no matter how clear you are about your story, talking through it while you map will help you discover the holes in your own thinking. Mapping

“Let’s come back and get to the details later. Let’s continue on and move this story forward.”

Get to the end of the story before getting lost in the details.

Notice how what we wrote on every card are short verb phrases that say what the specific type of user wants to do.

I personally believe that scope doesn’t creep; understanding grows.

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

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

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

What is the big idea? Who are the customers? Who are the companies we think would buy the product? Who are the users? Who are the types of people inside those companies we think would use the product, and what would they be using it for? Why would they want it? What problems would it solve for customers and users that they couldn’t solve today? What benefit would they get from buying and using it? Why are we building it? If we build this product and it’s successful, how does that help us?

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

I like using the term product discovery to describe what we’re really doing at this stage. Our goal isn’t to get something built; rather, it is to learn if we’re building the right thing. It just so happens that building something to put in front of customers is one of the best ways to learn if we’re building the right thing. I

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

The first slice cuts all the way through the functionality. Once they build all those pieces, they can see the functionality working from end to end. It wouldn’t work in all the situations it needs to, and if they shipped to users this way, those users would howl. But Mike and his team will be able to see the software running end to end. They’ll be able to put real data in it to see how well it performs, and they could apply some automated testing tools to it to see how well it scales.

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

My goals in approaching the exercise were to promote the efficiency of visualizing our work, demonstrate how putting the map together created shared understanding, and leverage the value of seeing the experience in an accessible format. The unexpected benefits were the effects of close collaboration—working as a team on a project where the goal was revealed through the work itself—and the moments of empathy for one another.

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 refine solution ideas—changing and refining the map as you go. 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 both delight people and help your organization reach its goals. 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 into even smaller minimum viable product experiments that you can place in front of a subset of your users to learn what’s really valuable to them. Slice out a development strategy. If you’ve sliced away everything you don’t need to deliver, you’ll be left with what you do need. Now slice your minimum vi...

The best solutions come from collaboration between the people with the problems to solve and the people who can solve them.

Story conversations are about working together to arrive at a best solution to a problem we both understand.

There’s some evidence that a fact wrapped in a story is much more memorable than the fact presented alone—22 times more memorable, according to psychologist Jerome Bruner.

One of the silly mantras that comes from my friend Luke Hohman is that you can deliver “half a baked cake, not a half-baked cake.”

Frame the idea from a business perspective. Understand customers and users and how you’re helping them. Envision your solution. Minimize and plan to identify the smallest viable solution and how you’ll build it.

Prioritize specific business goals, customers, and users, and then their goals, before prioritizing features.

Design thinking refers to a way of working originally described by a company called IDEO, and then later described and taught by Stanford University’s d.school.

You’ll learn the most from the stakeholders in your organization, customers who buy your product, and individual users who’ll use it when you put enough software in front of them that they can clearly see how it’ll help them reach one of their goals.