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

by Jeff Patton

The flow continues by choosing the people to focus on, the problems to solve, and the ideas to turn into working software. And from there—if the customers buy, and the users use it, and people are happy—eventually the business that sponsored this development will see the benefit it’s looking for. That’ll be reflected in things like increased revenue, lower operational costs, happier customers, or expanded market share. This makes lots of people inside your company happy. It should make you happy, too, since you’ve just helped your company stay healthy while making real people’s lives better in the process. It’s a win-win.

It’s that longer-term stuff that happens as a consequence of good outcomes that I’ll label impact. Outcomes are often something you can observe right away after delivery. But impact takes longer.

There’s always more to build than we have time or resources to build—always.

if you get the game right, you will realize that your job is not to build more—it’s to build less.

Minimize output, and maximize outcome and impact.

The trick is that you’ve got to pay close attention to the people whose problems you’re trying to solve. These include the people who will choose to buy the software to solve a problem in their organizations, the choosers, as well as the people who use it, the users. Sometimes they’re the same people. Sometimes they’re not.

I promise you that no business has the resources to make everyone happy—it’s just not possible. Don’t get me wrong here. Building more software faster is always a good idea. But it’s never the solution.

requirements—at

so I had to work hard to figure out the least I could build to make people happy. That may sound frustrating, but it’s actually the fun part.

I said, “Great, no problem. Tell me who they’re for and what problems this solves for them.”

who they’re for, and how they’re going to use this, and where it fits into the way they work.”

Remember: at the end of the day, your job isn’t to get the requirements right—your job is to change the world.

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 fr...

If you can work together effectively and create things that solve problems, you will rule the world. Or at least some small part of it inhabited by your products.

back to the basics of using stories. I hope you work together with others, telling stories about your users and customers and how you can help them. I hope you draw pictures, and build big sticky-note models. I hope you feel engaged and creative. I hope you feel like you’re making a difference. Because when you do it right, you are. And it’s a lot more fun, too.

Now it’s time to talk about the most fun you can possibly have telling stories, and that’s wh...

you. Using an Agile process and a story-driven approach doesn’t mean you have to sacrifice the big picture.

You can still have healthy discussions about your whole product and still see progress every few weeks.

how story maps solve one of the biggest problems in Agile development.

story mapping is a way to work with user stories as they’re used in Agile processes.

Because it has been proven time and time again that funny kitten photos on the Internet get far more attention than any manifesto could ever hope to.

Kent Beck (the guy who created Extreme Programming and first described the idea of stories)

Kent’s simple idea was that we should get together and tell our stories; that by talking we could build shared understanding, and together we’d arrive at better solutions.

Stories get their name from how they should be used, not what should be written.

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. Don’t feel bad if you didn’t arrive at it on your own. You would have eventually. But reading this book will save you weeks or months of frustration.

Story maps are for breaking down big stories as you tell them.

…at this point more than 120 USM [User Story Mapping] workshops have officially been recorded. A lot of POs just simply love it! It is simply a well-established approach at SAP.

The original idea of stories was a simple one. It turned our focus away from shared documents and toward shared understanding. A common way to use stories is to build a list of them, prioritize them, and begin talking about them and then turning them into software one at a time. That sounds pretty reasonable when you hear about it. But it can create some big problems.

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...

There’s a mantra that I like when I build story maps. I’ll say “talk and doc” (short for the verb document), which basically means don’t let your words vaporize. Write them down on cards so you can refer back to them later. You’ll notice how pointing to a few words on a card quickly helps everyone recall the conversation about it.

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

When working with a team to build a story map, or having discussions about anything, create a simple visualization to support your discussion.

One of the things that goes wrong is lots of ideas vaporize—that

is, we say them, and people nod as if ...

Get in the habit of writing down a little about your idea before explaining it. If you’re using cards or sticky notes, write down a few words about your idea immediately after thinking it. Explain your idea to others as you point to the sticky note or card. Use big gestures. Draw more pictures. Tell stories. Place the card or sticky into a shared workspace where everyone can see, point to, add to, and move it around. Hopefully, there will be lots of other ideas from you and others in this growing pile. I find that when I’m doing my best to listen to others, what they’re saying causes me to think of other ideas. I used to try to hold those ideas in my head and wait for a moment to inject them into the conversation, resorting to outright interruption if the time didn’t come soon enough. But then I realized I’d stopped listening to the person who was talking, as my limited brainpower was focused on recalling my great idea. Today, I simply scribble the idea on a sticky note and set it aside to wait for a better point in the conversation to inject it. Somehow writing it pops it out of my head so I can focus on what I’m hearing. And reading it from the sticky later helps me recall my idea and explain it.

One of the tough realities about software development is that there’s always more to build than we have time and money for.

So the goal should never be

to build it all. The goal is to minimize the amount we build. So the first question I asked Gary was, “Of all these different users and the things they want to do, if we were to focus on thrilling just one of those users, who would...

Reorganizing cards together allows you to communicate without saying a word.

As we talk and doc, and as I write down our conversation, we’re building something really important. No, it’s not that pile of cards on the floor. The something that’s really important is shared understanding. We’re getting on the same page. This is something Gary had never done

with anyone before about his product idea, at least not at this level of detail. He’d never even given it this much thought himself. The high points were in his head, sort of like the action scenes you’d see in a movie preview.

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 your story helps you find holes in your thinking.

Another mantra I use when mapping, at least at this stage, is “think mile wide, inch deep”—or for people in sane countries using the metric system: “kilometer wide, centimeter deep.” Get to the end of the story before getting lost in the details.

Focus on the breadth of the story before diving into the depth.

Chapter 2. Plan to Build Less There’s always more to build than you have people, time, or money for. Always. Speaking in absolutes like “always” and “never” always gets me in trouble. But with the statement above, I honestly can’t recall a situation where it wasn’t true although I have no sciencey data to back this up. No one has ever once come to me saying, “We were asked to add this new feature, and happily we had lots more time than we needed.” But one of the coolest things about using a story map is that it gives you and other collaborators a space to think through alternatives and to find a way to get a great outcome in the time that you have.