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

by Jeff Patton

There’s some evidence that a fact wrapped in a story is much more memorable than the fact presented alone—22 times more memorable, according to psychologist Jerome Bruner.

who, what, and why.

As a band manager, I want to upload an image so that I can customize my promo flyer.”

Template Zombies and the Snowplow The term template zombies comes from the book Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior by Tom DeMarco et al. (Dorset House). The name says it all, but I’ll give you the authors’ definition: Template Zombie: The project team allows its work to be driven by templates instead of by the thought process necessary to deliver products. As simple as that template is, it gets abused quite a bit. I see people really struggle to force ideas into the template when they just don’t fit. Stories about backend services or security issues can be challenging. I see people writing and thinking about things from their own perspective, not that of the people who ultimately benefit: “as a product owner, I want you to build a file uploader so that the customer requirements are met.” Nasty things like that.

It comes from what we learn when we tell the story.

It doesn’t need to be written in a template to be considered a story.

if I’m writing stories on sticky notes or cards, and they won’t be sitting inside a bigger story map, I’ll first give them a short, simple title, and then under it I’ll write:

Please don’t just talk about “the user.” Be specific. Talk about which user you mean. For Gary, he could talk about the band manager or the music fan.

Talk about the functionality from different users’ perspectives.

But for enterprise products, we’ll need to talk about the

people who make buying decisions, their organization as a whole, and how they benefit. Talk about other stakeholders. Talk about the people sponsoring the software’s purchase. Talk about others who might collaborate with users.

I like my stories to start with user tasks—the things people want to do with my software. But what about services like the kind way beneath the user interface that authorizes your credit card for a purchase, or authenticates you on an insurance website? Your users didn’t make a deliberate choice to get their credit cards pass:[authorized] or have their credentials verified. It’s OK to talk about the services and the different systems that

call them. It’s OK to talk about specific UI components and how the screen behaves. Just don’t lose sight of who cares, and why.

“Working software over comprehensive documentation.”

All those conversations—and the documentation that helps us recall them—are just a means to an end. Eventually we’ll need to build something.

That’s how telling a story works. Sydnie asked lots of who, what, and why questions. She asked about the context—where and when we’d be

serving the cake, and how many people would be there. During the conversations, we considered a few different options. We talked long enough to build shared understanding. And, because we’ve gotten lots of cakes from Sydnie, we already have some shared understanding about how they’ll look and taste when we get them. If we didn’t, we’d have wanted to see some pictures or taste some cake, and the phone wouldn’t have worked well for that.

The same thing happens when someone brings a story to a development team. Together they make decisions on specifically what to build, and the development team creates their work plan, composed of lots of development tasks. The development team includes testers, UI designers, technical writers, or whatever people and skills are necessary to create the software, so the tasks aren’t all about coding. And, just like Sydnie didn’t create her plan while she talked with me on the phone, the development team won’t likely create their plan during the story conversation. But they will listen, take notes, draw pictures, and gather lots of the details they’ll need to create their plan. At least, that’s the way we hope it goes.

Sydnie didn’t just stick to details about the cake, she asked me who it was for, what my daughter liked, how many people would be at the party, and lots of information that helped us decide together what the best cake should be. Sydnie wasn’t just asking for cake requirements, we were working together to decide on the best way to create a cake we’d all love. That’s the real spirit behind a story conversation.

If the story describes a solution that’s too expensive, consider a different solution that helps you reach the goal.

If the story describes a solution that’s affordable but big, break it into smaller parts that allow you to evaluate and see progress sooner. There’s a trick to breaking down large stories, and it helps me to keep the cake metaphor in my head. If you like cake, by now you might be getting hungry—especially if the cake you’re imagining is a particularly tasty one. Sorry about that. Let’s say our story describes a need for a lot bigger cake, like a super-giant wedding cake that will feed hundreds of people. If so, then it isn’t just cups of flour and sugar anymore, it’s sacks of flour and sugar. Most people break down software the

Don’t break down big things into big plans. Break big things into small things with small plans. Now the metaphor is really going to break down here, but stick with me for just one more minute. The way you approach a big software cake is to break it down into lots of little cupcakes. Each one is deliverable, and each one still has a similar recipe, with a little sugar, a little flour, an egg or two, and so on.

One of the biggest is to avoid the risks involved with not seeing, using, or “tasting” the software too late. You’re breaking big things down to small, evaluable parts so you can learn sooner.

With software, the cupcakes are portions of working software that allow users to evaluate if they can effectively complete a user task.

They may be portions of software that help expose a technical risk. But each piece helps us learn something.

half a baked cake, not a half-baked cake.”

Chapter 11. Rock Breaking The original idea of stories was pretty simple—write something on a card, talk about it, and agree on what to build. Then, complete the cycle by building it and learning from what you’ve built. That’s it—pretty straightforward, right? If you’ve been involved in software development for even a small amount of time, you know nothing is that simple. Stories go through a long journey with lots of conversations involving lots of people to move an idea for a product, feature, or enhancement into your product, and then move that product out to market. The good news is you can use stories and storytelling all the way through. And I promise that relying on stories and storytelling will help you all the way through.

A good rule of thumb is to break down stories to something that takes a couple of days to build and test.

A right-sized story from a development team’s perspective is one that takes just a few days to build and test. But, from a business perspective, it may make the most sense to release software to customers and users in bundles of multiple features. If you’re releasing a whole new product, that first bundle can be pretty large. This is the bundle I called a minimum viable solution earlier, and it’s focused on reaching specific outcomes for a target group of users. Ideally, businesses should be striving to release more of these more frequently—to push them closer to matching users’ need size, or a smaller and more specific business outcome. But, if you’ve got a large, diverse group of customers using your product, and you don’t have an infrastructure or business model that supports a more continuous release process, then your business’s releases

A right-sized story from a business perspective is one that helps a business achieve a business outcome.

But what’s the best tool we use for breaking down stories? That’s right: it’s conversation. Sometimes just a little thinking will do it, but if you use conversation and collaboration with someone else, then you’re spreading the shared understanding.

Conversations are one of the best tools for breaking down big stories.

An epic is a story that we expect is large, and know needs to be broken down.

I think of a theme as a sack I can use to collect a pile of stories that are related.

I could use a theme to collect a bunch of stories that are needed for a next release, part of the same feature, relevant to a particular type of user, or related in some other way. But my metaphor is slightly broken since the same story can be

in two different themes, but the same rock can’t be in tw...

You might simply refer to the theme by what it really is: your next release, the feature, or the stories relevant to a particular type of user.

Start with Opportunities The story’s journey starts as an idea. It may be an idea for a new feature, or a whole new product. It could be a change we’d like that would improve a feature we already have. It could be a problem we need to solve. But I’ll use the term opportunity, because it’s an opportunity for us to make something that we’ll benefit from. I suggest you name and build a list of these opportunities. I call them an opportunity backlog.

Our first good story conversation is a higher-level, who-what-why discussion. And our big goal is to make a go/no-go decision. Go doesn’t mean we’ll build it. It means we’ll go forward with deeper-dive discussions to really understand the story. But I don’t want to move forward with spending lots of time doing this if we can detect that it’s a bad idea from the outset. No-go is a polite way of saying “trash.” So, let’s call this a go-forward/trash decision. 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.

Use opportunity discussions to agree the problem is worth solving—to make a go-forward or trash decision.

Now that you’ve chosen to go forward, it’s time to dig much deeper. Use discovery to find a solution worth building. And don’t forget to really minimize that solution. Seek to make it as small and valuable as you can.

Who the customers and users are you believe will use your solution How they meet their needs today without your solution How the world would change for them with your solution How your solution might look and behave How long your solution might take to build There are a huge number of practices that can be helpful during discovery, especially story mapping. Story mapping can help you understand how people work today, and then map your ideas about how things will change for them after your solution is created. Discovery is where it’s critical to look hard at our assumptions and to do work to validate them. This may take the form of deeper analysis to understand business rules or outside regulations. It should take the form of spending time directly with customers and users to understand how they work. It should involve building prototypes of your solution

Use discovery conversations and exploration to find a small, viable solution.

Throughout discovery, you may choose to build small things that help you learn—specifically, UI or architectural prototypes.

Spike is a term used for bits of development or research we do with the explicit goal of learning. It’s a term that came from the Extreme Programming community to describe work that may not yield software we choose to ship. Use stories to describe spikes that get your team building something to learn.

That subset of stories that leads to a valuable product release is what I refer to as a release backlog.

We’ll use deep-dive discussions with developers and testers, and everyone else on the team who’ll build the software, to really dig into the details. These are our “last best conversations”—the conversations where we really need to agree on confirmation, or the acceptance criteria for the small parts of software we build—because the next step is building them. Since we know that it’s conversations that break up software, we’ll use these conversations to get our stories into the right size and shape to put into the next development sprint, or iteration.

Use deep-dive story workshops to discuss the details, break down stories, and really agree on specifically what we’ll build.

Sometimes they happen all at once during a planning session. In the Agile process Scrum, they may happen during what’s called a backlog grooming or backlog refinement session. Whatever you call these discussions, have them.

If you’re a product owner, UX designer, business analyst, or one of the other folks who helped decide what to build, don’t be afraid to get up from your desk to see how development is going. I promise that once you see something working, you’ll see something useful. And, more than likely, the person getting it working could use a little feedback.