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

by Jeff Patton

Shared documents aren’t shared understanding.

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

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

Alistair uses an altitude metaphor where sea level is in the middle, and everything else is either above or below sea level. A sea-level task is one we’d expect to complete before intentionally stopping to do something else. Did you write “Take a shower” in your list of tasks? That’s a sea-level task because you don’t get halfway through your shower and think, Man, this shower is dragging on. I think I’ll grab a cup of coffee and finish this shower later. Alistair calls these functional-level tasks and annotates them with a little ocean wave. But I’ll just call them tasks. Tasks like “Take a shower” break down into lots of smaller subtasks like “Adjust water temperature” and “Wash hair,” and, if you’re my wife, something involving an exfoliating loofah thing. Remember, people are different, and you’ll see behavior differences in the way they approach tasks. Alistair annotates these with a little fish because they’re below the ocean. Finally, we could roll up a bunch of tasks into a summary-level task. Taking a shower, shaving, brushing teeth, and all that other stuff you do in the morning after you get out of bed could roll up into a summary task. I’m not sure what I’d call it, though. “Getting cleaned up?” “Morning ablutions?” Ablutions is a silly word. Don’t use that. Use the goal-level concept to help you aggregate small tasks or decompose large tasks.

Maps are organized left-to-right using a narrative flow: the order in which you’d tell the story.

It’s her last card, and might very well be the last card in existence, so that makes it a historical artifact.

One of the luminaries in the Agile development community is my aforementioned friend, Alistair Cockburn, who once told me, “For every story you write, you need to put three into your backlog of stories.” I asked him why, and he said, “You just do.” I asked, “What should I write on the other two?” “It doesn’t matter what you write.” “What do you mean?” I asked, “I have to write something on them!” Alistair replied, “Well, if you have to write something on them, then write what you want on the first card, and on the second card write ‘Fix the first card.’ Then on the third card, write ‘Fix the second one.’ If you aren’t going around this cycle three times for each story, you’re not learning.”

Validated learning over working software (or comprehensive documentation)

very little of what we build is successful or has the real impact we hope for. I figure around 20 percent max. Then there is another 20 percent of things we do that are genuine failures—solutions that result in a negative impact. I’ve seen a variety of organizations that release a new, better version of their website and see sales decrease, or release a new version of their product that customers try and then demand the old version back. That’s the kind of failure I’m talking about. But it’s that 60 percent in the middle, give or take, that is neither success nor failure that’s the big problem. This is the stuff that we spend valuable development money creating, and in the end wish we hadn’t. Research from the Standish Group published in historic “Chaos” reports explains that between 64 and 75 percent of features are rarely or never used.[

Empathize, Focus, Ideate, Prototype, Test

Here are a few great ways to mess up a design process: Start without framing the business needs and target customer well. This’ll make it hard to prioritize who to focus on, and hard to tell if you’re finding a good solution. Spend a lot of time doing thorough research and making sense of what you’ve learned. You’ll never run out of things to learn—so why stop? Time-boxing might have been a good idea. Don’t spend any time at all talking to people and learning from them. After all, we’ve got a lot of data, and really, our solution ideas are great. We just need to get going on designing them. Fail to focus on specific problem, and instead try to solve lots of problems for lots of people. The more problems you solve the better, right? Except that big problems often result in big solutions. And trying to solve a problem for people with conflicting needs can result in a solution neither person likes. Consider multiple solutions, but only ask real designers to contribute solution ideas, because they’re the only ones trained to have good ideas. Don’t waste time considering multiple solutions, because the idea we have is so good. Beautifully craft a prototype that really looks real, but doesn’t work well enough for customers and users to really use it. After all, when they see it, they tell us it “looks really lovely.” Convince yourself and then others that this well-researched, professionally designed solution will work. After all, you’ve followed a rigorous design process. What ...

Great art is never finished, only abandoned.