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

by Jeff Patton

If you’re using an Agile development process, you’re likely filling backlogs with user stories. I’d assumed that since stories were such a common practice, it’d be a waste of time for me to write about them in this book. But I was wrong. In the decade and a half since stories were first described by Kent Beck, they’re more popular—and more misunderstood and misused—than ever before.

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

Even before I’d really understood why stories had that name, I realized that I could write down a bunch of stories—a sentence or a short title—on sticky notes or cards.

this one card could be something that might take a software developer just a couple hours to add to a product, or maybe a couple days or a couple weeks, or maybe a month—who knew? I didn’t—at least not until we started talking about it.

I got into a nasty argument while working with stories on my very first Agile project when I began a story conversation and learned that my story was too big. I’d hoped to get this story done in the next iteration. The developers I spoke with informed me otherwise. I felt like I’d done something wrong. The developers identified a small part we could talk about that could be accomplished in our next iteration. But I left frustrated that we couldn’t talk about the big picture. I really wanted to understand how much time the big thing I really needed would take. I’d hoped this discussion would accomplish that, and it didn’t.

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.

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.

the Tragedy of the Flat Backlog

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.

Scope doesn’t creep; understanding grows.

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.

Don’t Prioritize Features—Prioritize Outcomes

Validate that the problems you’re solving really exist.

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

Watch Out for What People Say They Want

Build to Learn

Iterate Until Viable

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.

Really Minimize Your Experiments

Map only what you need to support your conversation.

Plan to Build Piece by Piece

I call this first slice a functional walking skeleton—a term I borrowed from Alistair Cockburn. I’ve heard others call this a “steel thread” or a “tracer bullet.”