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

by Jeff Patton

Use conversations as you build to fill in details and give feedback on what’s being built. Evaluate Each Piece

Frequently reflect on product quality, your plans, and the way you work.

This first pass at evaluation in Scrum is called a sprint review and retrospective. Whatever you call these times to stop, review, and reflect, make sure you have them.

I’m looking to learn—and learning usually takes the form of “That’s not quite right” and “Now that I really use it, it would be better if…”

Learn by testing meaningful chunks of working software with customers and users.

Keep your progress and quality visible to stakeholders inside your organization.

Use metrics and face time with users to really learn if your target outcomes were met.

But you just made something. It’s a product. And a product’s life starts when it’s delivered. When you start paying attention to what people are doing with your product, I promise you’ll find opportunities to improve it. Write those down, and feed them back into the beginning of this model. That’s the real circle of life—or at least, the life of a story. And that’s a lot of rock breaking. So exactly who is supposed to do all that rock breaking? I’m glad you asked, because that’s what the next chapter is about.

In the Agile process Scrum, that person is called the product owner.

Requiring a single product owner to write all of the stories and be present for all story conversations doesn’t work.

In my vision of good product development, the product owner is a critical leader. He keeps the product and whole team focused on moving the same direction.

You might recall that story workshops is the term I give to that last best conversation where we decide specifically what to build. It’s here where the three amigos come in.

During this last best conversation, we really need to consider lots of details and alternatives for implementation, so we’ll need a developer from the team who’ll build the software—ideally, one of the developers who will actually work on it.

A tester—the first amigo—will often bring a critical eye into the discussion, spotting things that might go wrong sooner than most. The tester is often the best at playing the “What-About” game.

And, of course, we’ll need someone who understands what we’re building, who it’s for, and why we’re building it, so we’ll need a member of that core product discovery team. That person is the second amigo.

At this stage we’re often not introducing a new feature idea. We likely already did that back in discovery. Now we’ve more or less committed to build something, so it’s important to unders...

behave. So often the person involved in this conversation is a user experience designer or business analyst who’s worked through tho...

This group will work through the details and agree on specific acceptance criteria for the story.

It’s out of this conversation that we’ll have our best estimate of how long it will take to build and test the software.

And it’s often in this conversation that we’ll make decisions to split the story into smaller, “right-sized” development stories—those stories that ...

Story conversations happen continuously as we move ideas through software development. In every conversation, keep what’s valuable, what’s usable, and what’s feasible in the discussion. Include people who can speak to those things. Avoid design by committee by h...

When the solution is delivered, and the person in the client role receives what he asked for, he then gets an opportunity to use it and realize it’s not what he needs. He doesn’t get the outcome he imagined he would.

The real tragedy here is that the person in the client role understands his problem better than he’s able to predict what will solve it. And the person who understands the technology is often the most qualified to solve the problem because she knows how the technology she’s working with can help. What’s more, most technologists honestly want to help. They want to know the things they’re building are put to good use.

conversations about problems and solutions are replaced by discussions and agreements about...

As a business analyst in an IT context, that’s your job. Take the vision of your business stakeholders and help them make it a success. You can’t be just an order taker—you’ll need to behave more like a doctor. And sometimes this means telling your stakeholders things they don’t want

to hear. But, if you’re sincere about helping them succeed, they’ll see it and value your help.

When acting as product owner for other stakeholders’ ideas, take on the role of a producer who helps them succeed.

Stories are many things at once. We’ll use the word to refer to the card, to the chunk of software we build, and especially to the kind of conversations we have to make decisions about what we should build. Stories can describe very large opportunities, or the almost insignificant deliverable pieces that by themselves aren’t necessarily meaningful to customers and users. Working with stories is a continuous process of

conversation and discussion to break them down from big things to small things. And through all those conversations, we’re keeping not only what we could build in focus, but for whom, and why.

Story mapping is just one of the ways to help us break big things down while keeping the focus of the conversation on the people using your ...

If this is all starting to make sense, then you’ve made that big, necessary mindshift. It’s not a shift to use stories to document requirements, but a shift toward working with people more effectively, and together focu...

And that, I hope you’ll agree, is a be...

Initial discovery conversations, along with story maps, helped them get to a good starting guess. But, for both of them, it marked the beginning of a much longer journey to really discover a viable product.

This leads me to one of the biggest mistakes people make, and that’s actually believing their minimal viable solution will be successful.

We all thought the features we were adding would be valuable. But in the end we’d added a feature a few people used, but most didn’t, and we knew we’d end up supporting for the life of our product.

Research from the Standish Group published in historic “Chaos” reports explains that between 64 and 75 percent of features are rarely or never used.[

at, 75–90 percent of all software startups fail.[15]

What usually happened was people complaining about what we’d delivered not working the way they wanted. Sometimes they didn’t complain at all (which we’d find out later was a side effect of no one really using it). We’d then spend a lot of time pretending we were successful. For some of you, that might describe the way your company works today. And I’ll be honest with you: it’s still the way I often fall back into working. Don’t tell anyone. I’m supposed to be an expert.

design thinking.

Design thinking refers to a way of working originally described by a company called IDEO, and then later described and taught by Stanford University’s d.school. These days, it’s taught in a number of universities and used in lots of companies worldwide.

It’s called empathize because a critical outcome of doing the work is to understand how it really feels to be a user of your product. To do this you need to go to where users are, meet them, watch them work, and ideally work alongside them. Now, of course, if you build software for surgeons, no one expects you to become an amateur surgeon. But do your best to understand what it’s like to walk in their shoes. It’s important to remember that out of traditional

research, especially the quantitative hands-off stuff, we get data and not always empathy.

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

Use story maps here to map the way people do things today.

Include in them details of what you saw and learned. Focus on the pain points users have, and the rewards they seek. Use simple personas to build a good example user that synthesizes

what you’ve learned. Choose specific proble...

Really focus on one or a few problems. State them specifically.

The next step is ideation. If you were paying close attention in the last chapter, we talked about a simple practice called design studio. It’s an example of a good ideation approach. In common business practice where the first person to come up with a viable idea is the winner, it seems a waste of time to come up with lots of possible ideas. If you remember that your first obvious solutions are, well, obvious, then if really coming up with an innovative solution is important, think past that.

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

Build simple prototypes to explore your best solutions. Advance prototypes to a level of fidelity that allows users and customers to evaluate whether the solution really solves their problem.