Book Review: User Story Mapping

A High-Level View of Story Mapping

Story maps help teams to break down big stories. A team maps stories on a large wall using Post-it notes or cards, stickies, and pens. Story mapping comprises four steps: Think, Write, Explain, and Place—the Post-its. It is important to include team members from multiple disciplines when brainstorming ideas and to focus on the outcome, or benefit to users. As you’re designing a product, think about how the target audience would be using it.

Story mapping generates many goal-level tasks, or activities, and product features. The next step is prioritizing and scoping. Patton suggests using Post-it notes in several colors to indicate different levels and meanings. When a story map is complete, stories flow horizontally, in a narrative. Activities form the top row and their steps appear beneath them. Each step below the activities takes the form of a verb phrase such as “View my status” or “Start a promotion.”

Mapping stories helps teams find holes in their thinking and come close to completing requirements. It is more important to think through the high-level narrative than the edge cases and error conditions. The narrative flow is the backbone of the map, and it lets you tell stories about all the people who use the system and, for example, what they do to create and manage a Web site and its content. When you do mapping in this way, it prevents scope creep and grows understanding. “Focus on the breadth of the story before diving into the depth,” advises Patton.

In an agile environment, the right approach is to ask questions and develop a shared understanding of what you’ll build and what you should defer or reject. Patton suggests that teams should not hesitate to trash features that are not absolutely critical for the target users. If the team eliminates everything that is not a must-have, then selects a set of features, or cards, that would be sufficient to get feedback from the market, the chances of success are higher.

The book defines a minimum viable product (MVP) as a product that works, but without any bells and whistles that would not serve a basic user need. You derive the MVP from the story map by drawing horizontal lines below the backbone, or narrative. Try creating small MVPs. It would be wrong to create an MVP that doesn’t serve a specific purpose or provide a specific benefit to users.

A model for prioritizing the features of an MVP comprises the following:

• differentiator—what sets the organization apart from the competition
• spoiler—a feature moving into a competitor’s differentiated space
• cost reducer—a feature that results in cost savings for the organization
• table stakes—a feature that is absolutely necessary to compete

Patton strongly advocates starting with prototypes that look and feel real rather than creating actual software. This allows you to ”build to learn” without expending a lot of resources, which is helpful because, more often than not, project budgets are low. Patton cautions against misinterpreting the results from usability studies during which users indicate they would use a product. People who say this might not actually use the product.

Patton illustrates the concepts of an MVP and iteration through a clear example, shown in Figure 1, which demonstrates that, if the goal is to build a car, you should start by prototyping a roller skate rather than a wheel, because a skate can transport you, while a wheel cannot.

However, iterations alone are not enough. Patton suggests that every iteration must meet its complete objective—Build, Measure, and Learn—so you’ll be able to build the next iteration based on the user feedback you receive. To keep the objective of the book intact, the author doesn’t discuss software estimation much—and rightly so. But the chapter Plan to Finish on Time, which is about software estimation, felt a bit weak. Patton suggests that software estimations are more accurate when using story mapping because developers have a clear understanding of the product requirements.

Patton  goes on to discuss the difference between iterations and increments. The purpose of iterative thinking is evaluating and making changes to what you have already made, while incremental thinking lets you make additions. The book says there are three parts to releases:

• opening game—“Focus on the essential features or user steps that cross through the entire product. Focus on things that are technically challenging or risky. … Build just enough to see the product working end to end.”
• midgame—“Fill in and round out features. Add in stuff that supports optional steps users might take. Implement … tough business rules. … Start testing the product end to end for … performance, scalability, and usability”—“all the quality concerns.”
• endgame—Refine your release. Make it … more efficient to use. Using it “with real data and at scale, … you’ll find improvement opportunities that were hard to see from a prototype. … You’ll have feedback from users you’ll be able to apply.”

In the last chapter in this section, Patton teaches story mapping. He shows how to write a story, using a daily-activities exercise. This chapter helps readers understand writing down user tasks—the basic building blocks of a story map—and creating a map from them. You can also break down or aggregate tasks based on the importance to a product to users’ lives. Patton also shows how conducting mapping exercises with a team brings in different perspectives. Teams must build a shared understanding and focus on outcomes—rather than what to build—for their users.

Patton leads the reader through a story-mapping exercise in five steps:

• Write out all the steps in your story.
• Organize the story, from left to right.
• Explore alternative stories.
• Identify activities from tasks.
• Slice tasks on the basis of outcomes.

Figure 2 shows an example of a story map with its minimal tasks set off.

Build the story map by adding things belonging to these groups: painpoints, joys, rewards, questions, and ideas. This process is also called journey mapping. Patton describes the six simple steps of the story-mapping process:

1. Frame the problem. Who is the product for and why are we building it?
2. Map the big picture. What are the users’ painpoints and joys?
3. Explore. What are the different kind of users, alternative uses, and error scenarios?
4. Slice out a release strategy. What would be a minimal solution that would meet users’ goals?
5. Slice out a learning strategy. What parts of the minimal solution will you test with people to get feedback?
6. Slice out a development strategy. What parts of the minimal solution will you build earlier or later?

Patton adds credibility to story mapping by informing the reader that SAP—the German, multinational, enterprise-software corporation—is developing its own story-mapping tool for managing multiple, large projects.

How Stories Actually Work

In this section, Patton describes the experiences and practices of several established UX professionals and companies working in an agile environment. For instance, he discusses Kent Beck’s story-mapping ideas, bringing in his views on simplicity and acceptance criteria.

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

Stressing the importance of collaborative discussions within the agile teams, Patton refers to Ron Jeffries’s story 3Cs: Cards, Conversation, and Confirmation.

Returning to his vacation-photos story, Patton recommends recording videos of the story-telling process and capturing agreements as acceptance criteria. Using photos and videos from a story-mapping session can help you capture the rationale and arguments behind the story. Patton criticizes the hardwired usage of templates alone, calling teams that do this “template zombies.” “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. It doesn’t need to be written in a template to be considered a story,” says Patton. It’s the thinking and the manner in which you create stories that makes them valuable and useful.

It’s possible that people who are new to stories could forget things or need a reference while story mapping, so to ease recall, Patton provides “A Checklist of What to Really Talk About.”

• Really talk about who—all user types.
• Really talk about what.
• Really talk about why.
• Talk what’s going on outside the software.
• Talk about what goes wrong.
• Talk about questions and assumptions.
• Talk about better solutions.
• Talk about how long.

I was a initially a bit puzzled by the title of the Telling Better Stories chapter, but now I understand it. The stories are about talking out people’s views and opinions as the team continues to explore and fine tune the story map.

The story is not all on the cards, Patton reminds us. Rather, the story information is actually in people’s minds, and it’s possible that everyone has different thoughts about the same story or activity. It is important to capture as many conversations as possible—even if you need a different type of recording mechanism such as Excel or a dedicated mapping tool. It’s more important to use story maps correctly, Patton says, than to get a better tool for recording the story map. “We can use the wrong tool for the job, and we can also use the tool wrong.”

“There are many different kinds of conversations with different people for every story,” acknowledges Patton. Then, he describes the various formats for cards that might be best suited to the project type and scale, building on Ron Jeffries’s 3Cs to create the 5C concept shown in Figure 3.

You should not hand over the stories that you build during the story-mapping exercise as documentation to a new set of people because they could miss the big picture. Verbally conveying the full meaning of the stories to new team members helps with understanding. It is also important to evaluate the quality of the software that is produced by the teams who worked together during story mapping. In defining quality, Patton considers user-experience quality, functional quality, and code quality. To ensure quality, it is important to evaluate and iterate prototypes with real users. You must reapply your learnings from users to the original story to refine it. The core purpose of agile stories is learning. “Plan to learn, and learn to plan.” The development team further breaks down each card in the story into detailed tasks. It’s most effective if they also use story mapping. However, this may not always happen in practice.

“Don’t break down big things into big plans. Break big things into small things with small plans,” advises Patton. If a story describes a solution that’s affordable, but big, break it into smaller parts that let you evaluate your work and see progress sooner. You must deliver a functional product in every iteration. As Patton’s friend Luke Hohmann says, “You can deliver half a baked cake, not a half-baked cake.”

It’s normal to break a large project into smaller pieces. However, there is no predefined right size for a story.  If a story fulfills a user need, it’s the right size. It is important that the team continues the story conversation throughout the project, during daily stand-up meetings. Involving multiple people helps you avoid bottlenecks and brings in diverse viewpoints that help the team arrive at a better solution.

If a solution is valuable, usable, and feasible, it’s the right solution. The three main team members—the developer, tester, and UX designer—are called the “Three Amigos” in the book and define the stories’ acceptance criteria.

The Lifecycle of a Story: Putting Story Maps to Use

This section is about maintaining backlogs—along with identifying opportunities and having discovery discussions. Areas in a story map that contain many story cards indicate where opportunities may lie, helping with concept generation. The team should selectively choose opportunities and challenge every assumption. Trash all opportunities that don’t deliver a valuable outcome. “Dig deeper, trash it, or think about it,” recommends Patton.

Discovery lets you build a shared understanding and validate your learnings. The four essential steps to discovery are as follows:

1. Frame the idea from a business perspective.
2. Understand customers and users and how you are helping them.
3. Envision your solution.
4. Minimize and plan to identify the smallest viable solution and how you’ll build it.

Story mapping is a critical tool whether your team uses design thinking or Lean UX. You can achieve good outcomes only through effective conversations and user validation.

Points of Attention While Building Story Maps

This section of the book focuses on applying stories during sprints and learning from each sprint.  During the execution stage, some stories may be too big in scope. That is why conversations among the developer, tester, and UX designer is so important at this stage. Practice has shown that these meetings should occur before sprint-planning meetings. Patton suggests using the Fishbowl Collaboration pattern when there are higher numbers of participants. Throughout iterative execution, practice the ”Refine, Define, Build” mantra.

Finally, you can use story maps to evaluate release readiness. You could grade each use activity based on time to release, so all stakeholders would be aware of the release readiness of your entire product. Figure 4 shows how you can use maps to track progress and evaluate release readiness.

Patton recommends progressively breaking large stories into smaller chunks, just in time to add them to the next release backlog. Continue to learn while breaking large stories down into smaller ones. Build the smallest piece that helps you learn from users first. There’s no need to map the whole product at once. Map what you want to learn about.

He advises teams to review the product as it is built, build measurement parameters into products to track feature usage, and set time aside for usability testing for every release. “Improvements made after release are the most valuable,” says Patton. He expresses the hope that readers can further improve the story-mapping technique by sharing their own experiences. He concludes the book by quoting Leonardo da Vinci: “Great art is never finished, only abandoned.”

References and Bibliography

The Bibliography comprises just two pages; the Index, 10 pages. Both are in a legible font.

Writing and Copyediting

Patton writes smoothly and concisely about concepts. He has highlighted key takeaways by using different font sizes. The simple examples he provides are very relatable. Patton uses a touch of humor, while still ensuring that readers understand critical concepts. Each chapter shares valuable learnings from the industry.

Illustrations

The book uses no stock photos. Many figures are hand-drawn illustrations. Photos include handwritten annotations that appear to have been sketched using whiteboard markers, thus evoking a hint of a workshop experience that is truly representative of the subject of story mapping. The figures highlight the most important content. However, the images are grainy, which affects the overall reading experience to some extent.

Book Design

If the Table of Contents had included a brief description of each chapter, it would have enhanced the interest of those readers who start reading from Chapter 1 instead of the Preface and Foreword. In each chapter, a special boxed section highlights practical material or provides a summary that gives a quick overview of the chapter’s content. The book’s figures are a mix of drawings and photographs with handwritten annotations. These capture the feeling of having a real-life experience at work and made the book a smooth reading experience for me.

The typeface is clear and pleasing. The body-text font size is large enough that reading doesn’t stress the eyes.

The book uses subheadings effectively to clearly communicate its organization. The book design highlights quotations and important notes. There is no color coding for the sections of the book—or bleeds that go to the edges of pages. This isn’t really a problem because the book isn’t very long. It’s the hand-drawn and photographic images that put this book design ahead of other books I have read.

Conclusion

The book is a fabulous work on story mapping and its applications, benefits, and pitfalls. It presents numerous ideas that help to bridge the gaps between designers, developers, and business representatives and build shared understanding. User story maps can help resolve the challenges of working together effectively to create better products.

The book covers the complete product lifecycle—from concept to delivery. The last few chapters of the book felt harder to read and may demand a second reading. That said, the book is a must read for everyone working in agile or Lean development, as well as those who are just starting to explore these approaches. I believe this book would be immensely helpful to UX professionals who are trying to apply user story mapping in their work, and I highly recommend the book to anyone working in product development.