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

by Jeff Patton

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 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 for their services in the form of documents and scheduling meetings.

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

Shared documents aren’t shared understanding.

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.

Stop trying to write the perfect document.

The real goal of using stories is shared understanding.

“Jeff, I need you to make these changes to the product you’re working on.” I said, “Great, no problem. Tell me who they’re for and what problems this solves for them.” Her response? “They’re the requirements.”

the word requirements actually means shut up.

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

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

There’s always more to build than you have people, time, or money for. Always.

Globo.com must always finish on time. And, since that’s the reality of its business, Globo.com is good at it. That’s not because the company is faster than everyone else — sure, it’s fast, but it’s not that fast. It’s because it’s smart about doing less.

I personally believe that 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.

your job isn’t to build software, it’s to change the world.

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.

Map only what you need to support your conversation.

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

Use incremental thinking to make additions.

Tasks are like rocks. If you take a big rock and hit it with a hammer, it’ll break into a bunch of smaller ones. Those smaller rocks are still rocks. It’s the same thing with tasks. Now I don’t know when a rock is big enough to be called a boulder, or small enough to be called a pebble, but there’s a cool way to tell a big task from a small task.

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.

You’ll find people won’t argue about things that do matter. For example, putting “Get dressed” after “Take a shower” isn’t just a matter of preference.

Template Zombie: The project team allows its work to be driven by templates instead of by the thought process necessary to deliver products.

the real value of stories isn’t what’s written down on the card. It comes from what we learn when we tell the story.

Handing off all the details about the story to someone else to build doesn’t work. Don’t do that.

By the way, “meeting” is often the euphemism we use for unproductive collaboration.

In a traditional process, learning gets referred to as scope creep or bad requirements. In an Agile process, learning is the purpose.

Don’t break down big things into big plans. Break big things into small things with small plans.

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

It looks like a rock until it’s dropped on your foot. Then it feels like a boulder.

Remember, there’s always too much to build, and killing a mediocre opportunity before it wastes too much of everyone’s time should be celebrated.

I hear the term triad used when there are two people, four people, or even more on the discovery team, since it’s the three concerns — valuable, usable, and feasible — we’re talking about, not three bodies.

The person in the vendor role can cite all sorts of excuses for the delay, including lack of details in the requirements she was given, or just “bad requirements.” The client can blame inaccurate estimation — which no one seems to notice is an oxymoron.

Try to make your working relationships much more like a good doctor-patient relationship, and much less like a waiter-diner’s.

Step past the mythical certainty of “requirements,” and take a moment to explore the discovery of ideas using examples and journeys as your guide.

But it had learned that “the faster you deliver crap, the more crap you get.”

there was little correlation between the quantity of software it built, and the outcome and impact it got from it.

Talk directly to customers and users. Experience the challenges you’re helping them with firsthand.

Deliberately come up with multiple possible solutions to customer and user problems.

To avoid a backlog filled with lots of tiny stories, take a bundle of stories that go together, and write all their titles on a single card as a bulleted list. Summarize those titles with a single title on your new card. Voilà, you’ve got one big story.

We sometimes forget that another name for software development is knowledge work. When we forget that and instead fixate on documents and process, it turns into something dry and secretarial.

When adding a feature into an existing product, map a little ahead of where the feature begins in your users’ story, and a little beyond where it ends. Don’t map your whole product.

it’s not the software we really wanted — it’s the outcomes we get after the software is delivered and put into use.

Build metrics into your product that allow you to track usage of new features

Software is never really done.

Outcomes are never insured.