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

by Jeff Patton

But this chunking has some negative consequences. One of these is that it’s easy to lose the big picture of what a software system should do. You can end up with a jumble of pieces that don’t fit into a coherent whole. Or you can end up building a system that isn’t really helpful to the users, because you’ve missed the essence of what’s needed by getting lost in the details.

Perhaps the biggest disappointment for me in the decade of the adoption of Agile methods is the way that many programmers see stories as a one-way communication from analysts to them. Right from the beginning, stories were supposed to spark conversations. If you really want to come up with effective software to support an activity, then you need to look to those who build software as a vital source of ideas for its capabilities, because it’s programmers who know best what software can do. Programmers need to understand what their users are trying to achieve and should collaborate in building the stories that capture those users’ needs. A programmer who understands story mapping can better see the broader user context and can participate in framing the software—leading to a better job.

In fact, if you only get two points from this book, I’ll be happy. And those two points are right here in this chapter: The goal of using stories isn’t to write better stories. The goal of product development isn’t to make products.

recall a situation where two people believed they were in agreement on a feature they wanted to add to the software, but later found out that the way one imagined it was wildly different from the other.

The answer is just to stop it. Stop trying to write the perfect document. Go ahead and write something, anything. Then use productive conversations with words and pictures to build shared understanding.

The real goal of using stories is shared understanding.

Stories in Agile development get their name from how they should be used, not what you write down.

stories are an invitation for shared umderstanding.

For better or worse, this is the way documents actually work.

yes it is. reminds me of clints just make this dashboard comment.

And we don’t measure outcome by the number of features delivered, or what people have the capability to now do. We measure what people actually do differently to reach their goals as a consequence of what you’ve built, and most important, whether you’ve made their lives better.[

good outcome focus definition

But if you get the game right, you will realize that your job is not to build more—it’s to build less. Minimize output, and maximize outcome and impact.

At one point, the head of a different team came to me and said, “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.” I replied, “I get it. Just tell me a bit about who they’re for, and how they’re going to use this, and where it fits into the way they work.” She looked at me like I was stupid and said to me one last time with an air of finality, “They’re requirements.” It was at that moment that I learned that the word requirements actually means shut up.

powerful story

The original idea of stories was a simple one. It turned our focus away from shared documents and toward shared understanding.

Think — Write — Explain — Place When working with a team to build a story map, or having discussions about anything, create a simple visualization to support your discussion. One of the things that goes wrong is lots of ideas vaporize—that is, we say them, and people nod as if they’ve heard. The ideas are not written down or referred to. Then, later in the conversation, the ideas come up again and unfortunately need to be re-explained because people didn’t really hear or forgot them. Get in the habit of writing down a little about your idea before explaining it. If you’re using cards or sticky notes, write down a few words about your idea immediately after thinking it. Explain your idea to others as you point to the sticky note or card. Use big gestures. Draw more pictures. Tell stories. Place the card or sticky into a shared workspace where everyone can see, point to, add to, and move it around. Hopefully, there will be lots of other ideas from you and others in this growing pile.

Reorganizing cards together allows you to communicate without saying a word.

Story mapping is all about having a good old-fashioned conversation and then organizing it in the form of a map. The part that most people look at is the map—that left-to-right shape with the steps people take to tell a big story. The top to bottom is about the details. But the critical parts that frame the product and give more context are often hung above and around the map. They’re the product’s goals, and information about its customers and users. If you keep a map on the wall, you’ll find it’s good idea to add user interface (UI) sketches and other notes around the map.

I like the dimensional communication that can be had. Could our BRDs turn into these? 1. Setting up the account 2. Provisioning lines 3. Creating hunt groups 4. End user modificatons 5. Billing and reporting

I sat down with them and reminded them of something they already knew: “I understand that you’re different teams because you’re focusing on different areas, but it’s a major revision of one content management system. You’ll have to release together. You can’t plan a release until you can see it all together. You’ve got to visualize all these dependencies.” They agreed and quickly went to work reorganizing their individual backlogs into a map. Within a few hours they built a map on the wall using sticky notes that told the story of their content management system. I wasn’t in the room while team members worked together to build the map. But when I returned later in the day, I was amazed at how quickly they’d built it. They were pleased with themselves, and had every right to be. They’d made sense of several complex backlogs, organizing them into one coherent product story. And now each team could see where its work fit into the big picture.

Alianza could benefit from doing this with some of the large cross-team projects we are working on. Does everyone know what we are doing holistically?

One of the criticisms people sometimes make about story mapping is that every time they sit down and create story maps, they end up with way too much. But it’s my belief that we’re just finding the stuff now that would have bitten us later on, and that’s a good thing.

That is my fear...you have an overwhelming amount of information, but it is just seeing all options/paths and choosing.

it’s just that estimating the time to do something we’ve never done before is something we suck at.

Yep. Custom craftsmanship (in the middle of the spectrum between a factory and art)

Focus on outcomes—what users need to do and see when the system comes out—and slice out releases that will get you those outcomes.

Focusing on specific target outcomes is the secret to prioritizing development work. And the opposite is true as well; that is, if you don’t know what your target outcomes are—the specific benefits you’re trying to get—then prioritization is close to impossible.

The minimum viable solution is the smallest solution release that successfully achieves its desired outcomes.

I like this better than Minimum Viable Product as well

The best product owners, like Eric, help their entire team take ownership of the product.

By now Eric and his team, after talking to customers, had specific ideas for the type of solution they could build that users could use, and by doing so get the benefit their employers wanted. Now, here’s where Eric and his team could have gone “all in”—where they could have bet it all. They could have built a backlog of stories that described their solution and set a team to work building it. Because they’re smart people, they’d have used a story map to move from the big idea to the specific parts to build. But, because they’re really smart, the last thing they’re going to do at this point is to build software.

Good = backlog with good stories Great = backlog with good stories with shared understanding provided by story mapping Best = Prototype the shared understanding, validate it with customers, then put the stories in the backlog

Prototype and test with users to learn whether your solution is valuable and usable.

Able to check the valuable an usable boxes with the prototype Feasibility and viability are internal concerns.

Eric may have started this whole process with an idea about what the minimum viable product might be, but he’s purposely built something less than minimal to start with. He’s then adding a bit more every month.

This is interesting. Start with very minimal to shorten the feedback cycle.

Treat every release as an experiment and be mindful of what you want to learn.

What Eric did is the heart of the build-measure-learn loop described by Eric Ries. And by Ries’s definition, each release that Eric shipped was a minimum viable product. But you can see that it wasn’t viable in the eyes of his target customers and users—at least, not yet. For that reason, I like referring to Ries’s MVP as a minimum viable product experiment—or MVPe for short. It’s the smallest thing I could build to learn something. And what I learn is driving toward understanding what’s really viable in the eyes of my target customers and users.

Ha, MVPe (Minimum Viable Product experiment) to get around the debate.

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

He doesn’t get to walk away after he’s identified a good solution. His role changes now, and he’s a bit more like a director in a movie. He’s got to be there as every scene is shot. And he’s got to decide which scenes should be shot first, and which scenes get shot last. He knows that in the end the entire movie needs to come together and look like one coherent whole.

I like the analogy to a movie director for the work that happens during the delivery phase.

I call this first slice a functional walking skeleton—a term I borrowed from Alistair Cockburn. I’ve heard others call this a “steel thread” or a “tracer bullet.”

"Functional Walking Skeleton" Ha

These are the “predictably unpredictables”—a concept closely related to Donald Rumsfeld’s “unknown unknowns.” Don’t pretend they don’t exist. You know they do.

"Predictably Unpredictables" ha

Mike and Aaron worked together with developers they trust early on to get an initial time estimate. They treat it as a budget. And they actively manage it. With every small piece the team builds, they can measure how long that piece took to build. They treat what they’ve built as spending against their budget. They may find that they’re halfway through their budgeted time, but only a third of the way through building the feature. Certainly they didn’t expect that, but now they’re aware and they can do something about it. They could borrow some budget from other features they’re working on. Or there may be small changes they could make to the feature that won’t substantially change the benefit users get. Or they could just face the music and see what they can do to change expectations with the people they’ve promised delivery to.

I like that idea. Here is a "budget." Let's see what our spend rate is, so we can either cinch the belt somehow or ask mom and dad for more money.

Great art is never finished, only abandoned. — Leonardo da Vinci

In software development, iterate has two meanings. From a process perspective, it means to repeat the same process over and over. That’s why the development time-box used in Agile development is often called an iteration. But when you use this term to describe what you’re doing with the software you build, it means to evaluate and change it. And changing software after it’s built is too often seen as a failure. It’s where terms like bad requirements or scope creep get used to reprimand the people who made decisions about what to build. But we all know that change is a necessary result of learning.

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.

Good way to find a good size

Six Simple Steps to Story Mapping I can boil down the last four chapters into just six steps. You might be thinking, Why didn’t he do that in the first place? But then I’d have skipped telling you the stories, and just given you the requirements. And that just doesn’t work. While I know there are lots of right ways to build up and use a story map, I have found that the following six-step process works well for me: Frame the problem. Who is it for, and why are we building it? Map the big picture. Focus on breadth, not depth. Go a mile wide and an inch deep (or a kilometer wide and a centimeter deep, for my friends in the rest of the world). If you don’t have a clear solution in mind, or even if you think you do, try mapping the world as it is today, including pains and joys your users have. Explore. Go deep and talk about other types of users and people, how else they might do things, and the kinds of things that can (and likely will) go wrong. For extra credit, sketch, prototype, test, and refine solution ideas—changing and refining the map as you go. Slice out a release strategy. Remember: there’s always too much to build. Focus on what you’re trying to achieve for your business, and on the people your product will serve. Slice away what’s not needed to reveal minimum solutions that both delight people and help your organization reach its goals. Slice out a learning strategy. You may have identified what you think is a minimum viable solution, but remember that it’s a hyp...

the two most important things that make stories work: Use storytelling with words and pictures to build shared understanding. Don’t just talk about what to build: talk about who will use it and why so you can minimize output and maximize outcome.

The best solutions come from collaboration between the people with the problems to solve and the people who can solve them.

Stories get their name from how they’re supposed to be used, not from what you’re trying to write down.

In the book Extreme Programming Installed, Ron Jeffries et al. (Addison-Wesley Longman Publishing) describe the story process best: Card Write what you’d like to see in the software on a bunch of index cards. Conversation Get together and have a rich conversation about what software to build. Confirmation Together agree on how you’ll confirm that the software is done. If it sounds simple, it’s because it is. Just remember, simple isn’t easy.

I like the 3 Cs

Story conversations are about working together to arrive at a best solution to a problem we both understand.

The conversation goes best if it includes lots of things such as simple personas, workflow diagrams, UI sketches, and any other traditional software model that’ll help explain things. That way, you don’t have to just wave hands—you can point a lot, too.

In his book Agile Software Development: The Cooperative Game (Addison-Wesley Professional), Alistair Cockburn coined the term information radiator to describe how big, visible information on the wall radiates useful stuff into the room. People walking by look at it and engage with it. When the information is alive and useful, lots of conversations end up at the wall, where people can point to and add to the information accumulating there.

When I tell people how companies like Atlassian use tools, they’re usually surprised. They’re often surprised because they’ve been trying to use tools as a replacement for whiteboards and sticky notes. And, predictably, they’ve been struggling with that. It may be that they’re using the wrong tool for the wrong job, or using the right tool wrong. To figure out what might be going wrong, it’s best to look at the job first, and not the tool.

When collaborating remotely, use tools that allow everyone to see, add to, and organize the model concurrently.

The most important thing here is that all these people are armed with the same picture in their heads: the picture they built while talking together. I’m going to pause here for effect. Now, I’m going to say this next part slowly, so you should read it slowly. Handing off all the details about the story to someone else to build doesn’t work. Don’t do that.

Nice. "Don't do that" ha.

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

Yes...especially for devs.

Effective discussion and decision making goes best with small groups of two to five.

In a traditional process, learning gets referred to as scope creep or bad requirements. In an Agile process, learning is the purpose. You’ll need to plan on learning from everything you build. And you’ll need to plan on being wrong a fair bit of the time.

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.” Half a baked cake may not be enough to feed a wedding party, but it’s enough to taste and leave everyone looking forward to the rest of the cake.

Really like that mantra