Formats: Paperback, ebook, and Safari Books Online. 324 pages in print.
Print ISBN: 978-1-4919-0490-9 and 10:1-4919-0490-9
Ebook ISBN: 978-1-4919-0485-5 and 10:1-4919-0485-2
List Price: Paperback, $34.99; ebook, $29.99
If you are or soon will be working in an agile development environment, User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton is a must read for you. This book details story-mapping techniques and explains why they are important for teams that create products to meet user needs. According to Patton, user story mapping is not about creating set of written requirements, but a way of thinking. Telling stories through words and pictures builds understanding and helps solve problems for organizations, customers, and users.
The most important job we have is to focus on the outcome and the impact of the products we are creating. Taking a slightly philosophical view of the importance of project outcomes, Patton writes, “The truth is, your job is to change the world.”
Patton likens requirements documents to vacation photos because they mean a lot more to the people who were on the journey than they do to other people. The difference is that the people on the vacation recall their experiences in the form of a story. Those who were not on the vacation can appreciate only the surface beauty of the photograph—for instance, nature scenes or people’s smiles—because they don’t have the full picture. In comparing the vacation-photo scenario to requirements documentation, Patton said, “What’s most important isn’t what’s written down—it’s what we remember when we read it.”
Patton believes story mapping requires a paradigm shift in team members’ mindsets, moving from “sharing requirements” to developing a “shared understanding.” The book focuses on understanding target audiences, collaboration, and user validation of prototypes. Short, snappy phrases such as “talk and doc,” “build less,” and “what abouts” make core concepts of agile development easy to remember.
The book uses simple language, and I—who am not a native English-language reader—stayed interested from start to finish. Patton’s conversational and often humorous writing style is impressive. It’s easy to relate to the book’s useful references and real-life situations. In my role as a consultant running UX workshops for established organizations and start-up teams, I have faced similar situations to those that Patton describes. He addresses these situations in a practical way, with just the right level of detail. He also refers the reader to related concepts such as Lean UX, concept generation, and opportunity.
This book had a humble beginning: “This book was supposed to be a small thing … a pamphlet, really. I set out to write about a simple practice I called story mapping,” Patton writes. “Story mapping keeps us focused on users and their experience, and the result is a better conversation and, ultimately, a better product.”
The book comprises 18 short chapters—whose brevity helps maintain reader interest—as follows:
Read This First
Chapter 1: The Big Picture
Chapter 2: Plan to Build Less
Chapter 3: Plan to Learn Faster
Chapter 4: Plan to Finish on Time
Chapter 5: You Already Know How
Chapter 6: The Real Story About Stories
Chapter 7: Telling Better Stories
Chapter 8: It’s Not All on the Card
Chapter 9: The Card Is Just the Beginning
Chapter 10: Bake Stories Like Cake
Chapter 11: Rock Breaking
Chapter 12: Rock Breakers
Chapter 13: Start with Opportunities
Chapter 14: Using Discovery to Build Shared Understanding
Chapter 15: Using Discovery for Validated Learning
Chapter 16: Refine, Define, and Build
Chapter 17: Stories Are Actually Like Asteroids
Chapter 18: Learn from Everything You Build
The author has written the book in such a way that it makes sense to each different type of reader—UX designers, product owners, and development team members. To improve ease of reference, the book would have benefited from its chapters being arranged in three or four parts, based on the high-level benefits Patton intended to provide the readers. Each of these parts could have had a specific purpose, as follows:
Chapters 1–5 provide a high-level view of story mapping.
Chapters 6–12 describe how stories actually work, highlighting basic concepts.
Chapters 13–15 present the lifecycle of a story and show how to put story maps to use when developing software products.
Chapters 16–18 explain what to focus your attention on and points to consider when building story maps.
In the following sections, I’ll summarize the book’s content.
This book includes no introduction, but readers won’t miss it. Patton creates interest in story mapping right from the beginning of the Preface. In addition to describing the concept concisely, he presents a convincing rationale for his writing the book. The book’s target audience and conventions are well defined, letting readers know where they need to pay the most attention and where they can skim.
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:
Frame the problem. Who is the product for and why are we building it?
Map the big picture. What are the users’ painpoints and joys?
Explore. What are the different kind of users, alternative uses, and error scenarios?
Slice out a release strategy. What would be a minimal solution that would meet users’ goals?
Slice out a learning strategy. What parts of the minimal solution will you test with people to get feedback?
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:
Frame the idea from a business perspective.
Understand customers and users and how you are helping them.
Envision your solution.
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.
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.
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.
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.
In 2012, Kuldeep co-founded UXArmy to provide UX consulting services and remote usability-testing tools to large and medium-size companies such as Motorola, Amway, propertyguru.com, and Nippon Paints, in Singapore and Malaysia. With nearly a decade of UX design and research experience, Kuldeep spent over eight years at Philips, working on consumer products. His roles at Philips included UX Architect, User Research, and Global UX Technology Manager. Kuldeep is a listener, problem solver, and motivator, and continually learns from new experiences. To benefit the UX community in Singapore, Kuldeep formed the User Experience Southeast Asia (UXSEA) Society there and is currently its President. Read More