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

by Jeff Patton

Right from the beginning, stories were supposed to spark conversations.

developers are using their construction method as a design tool, but the two are not interchangeable.

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.

It is really hard to express a design problem in programming terms, and it is equally hard to express a development problem in design terms.

Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries. Good teams get their inspiration and product ideas from their scorecard KPIs, from observing customers struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers. Good teams understand who their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing

solutions that not only work for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders.

Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold m...

Good teams love to have brainstorming discussions with smart thought leaders from across the company. Bad teams get offended when someone outside thei...

Good teams have product, design, and engineering sit side-by-side, and embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their respective functional areas, and ask that others make requests...

Good teams are constantly trying out new ideas in order to innovate, but doing so in ways that protect the revenue and the brand. Bad teams are st...

necessary to create winning products, such as strong interaction design. Bad teams don’t even know wh...

Good teams ensure that their engineers have time to try out the discovery prototypes every day so that they can contribute their thoughts on how to make the product better. Bad teams show the prototypes to th...

Good teams engage directly with end users and customers every week to better understand their customers, and to see the customer’s response to their latest i...

Good teams know that many of their favorite ideas won’t end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome. Bad teams just build what’s on the ro...

Good teams understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed com...

forced labor. Bad teams complain they are slow because their colleagues are n...

Good teams make high-integrity commitments after they’ve evaluated the request and ensured they have a viable solution that will actually work for the customer and the business. Bad ...

Good teams instrument their work so that they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consid...

Good teams integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers. Bad teams test manually at the end of a painful...

Good teams obsess over their reference customers. Bad teams obse...

Good teams celebrate when they achieve a significant impact to the business KPIs. Bad teams celebrate when ...

The goal of using stories isn’t to write better stories. The goal of product development isn’t to make products.

Shared understanding is when we both understand what the other person is imagining and why.

However, if we get together and talk, you can tell me what you think and I can ask questions. The talking goes better if we can externalize our thinking by drawing pictures or organizing our ideas using index cards or sticky notes. If we give each other time to explain our thoughts with words and pictures, we build shared understanding. It’s at this point, though, that we realize that we all understood things differently. That sucks. But at least now we know.

It’s not that one person is right or wrong, but that we all see different and important aspects. Through combining and refining our different ideas, we end up with a common understanding that includes all our best ideas.

externalizing our ideas is so...

story-driven process needs lots of documents to work. But those documents don’t always look at all like traditional requirements documents. It takes talking and sketching and writing and working with sticky notes or index cards. It’s pointing to documents we brought into the conversation and marking them up with highlighter and scribbled notes. It’s interactive and high energy.

Software Isn’t the Point

Also not just “a point”

Everything between the idea and the delivery is called output. It’s what we build.

But, while it’s necessary, the output isn’t the real point; it’s not the output that we really wanted. It’s what comes after as a result of that. It’s called outcome.

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

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

Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get fr...

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.

didn’t coin the term story mapping, however, until 2007.

when you tell someone about a great idea and he says, “Yeah, we do something like that, too.” It’s not an invention, it’s a pattern. 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.

you didn’t arrive at it on your own. You would

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

Our first conversation focused on framing his product idea.

We listed the different types of users.

We talked about what benefits they would get, and asked why they would use the product and what we thought they would do with it. What was in it for them?

Mapping your story helps you find holes in your thinking.

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

Signing up Changing my service Viewing my band stats Working with my show calendar Working with my audience Publicizing a show Signing up for a band’s email list Viewing promotions online

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

What are the specific things they’d do here? What are alternative things they could do? What would make it really cool? What about when things go wrong?

Story mapping is all about having a good old-fashioned conversation and then organizing it in the form of a map.