Top 5 takeaways from User Story Mapping

The summary of “User story mapping” by Jeff Patton

“User story mapping: Discover the whole story, build the right product” is a classic read for anyone who builds software. This is a quick summary of the book, and if you are interested in knowing more about this process:

  • The book can be purchased here
  • The full overview and live session with Jeff Patton can be found on YouTube
  • Learn more about Jeff and his work on his website

User story mapping summary and the top 5 key takeaways

User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton details story-mapping techniques and explains why they are important for teams that create products.

Why we need user story mapping

User story mapping is not about creating a set of written requirements, but a way of thinking. Telling stories through words and pictures builds understanding and helps solve problems for organisations, customers, and users.

The most important job we have is to focus on the outcome and the impact of the products we are creating.

The book speaks about the problems of requirements and the way user stories are being used. Patton gives two really clear examples of why requirements in isolation don’t work.

The first example is from cakewrecks.com

In this and other examples on the site you can imagine the scenario. Somebody calls up a cake place and tells them their requirements, somebody writing that down, and then following the instructions literally.

The second example is vacation photos.

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. Take, for example one of my vacation photos below.

Those of you who were not on my vacation can appreciate only the surface beauty of the photo above because you don’t have the full picture. But what you dont know if that this was at Hamilton Island, the only day of sunshine in the entire trip, and was our last holiday before we had a baby. And it’s possibly the last vacation with just my wife and I for a very long time.

“What’s most important isn’t what’s written down — it’s what we remember when we read it.”

Programmers need to understand what their users are trying to achieve and should collaborate in building the stories that capture those users’ needs.

Patton believes that story mapping requires a paradigm shift in team members’ mindsets, moving from “sharing requirements” to developing a “shared understanding.”

Key takeaway #1:

The goal of using stories isn’t to write better stories. The goal of product development isn’t to make better products

The real goal is to change the world. Jeff explains that our goal is to take our target persona’s from where they are now, to where they want to be.

Getting back to the limitations of requirements, story mapping fit’s in as the tool that enables the team to have shared understanding. Shared understanding keeps us focused on users and their experience, and the result is a better conversation, ultimately a better product, and a higher chance of changing the world.

The high-level view on what story mapping is

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.

But before you start story mapping, the book talks about three principles and is key takeaway # 2:

Plan to build less, plan to learn faster, plan to finish on time

A story map is a visual representation of user stories.

At the top of the page are the use activities, and under each of the user tasks and stories. The map moves from left to right and follows the user journey.

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.

At this point it is more important to think through the high-level narrative than the edge cases and error conditions.

Jeff advises 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.

At this stage the map will become at lot bigger than people first imagined. The book advises this is completely normal and expected.

“Scope doesn’t creep, instead understanding grows”

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 then talks a lot about MVP’s and Jeff’s view on defining what comprises an MVP. And one of the main points is to build to learn, and to create iterations to meet a complete objective.

The book then 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.

A deep dive into story mapping and how to tell better stories

This next section of the book gets into more detail into user story mapping. Jeff 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 us through the story-mapping exercise in 6 steps:

  1. Frame the problem — who is it for and why are we building it
  2. Map the big picture — focus on the breadth, not the depth.
  3. Explore — go deep and talk about other types of users and people, how else they might do things and the kind of things that can go wrong
  4. Slice out a release strategy — focus on what you are trying to achieve for your business and on the people your product will serve
  5. Slice out a learning strategy — use the map and discussions to find your bigger risks, slice your map into minimum viable product experiments
  6. Slice out a developmental strategy — focus on building things early that help you learn to spot technical issues and development risks sooner

Jeff describes the experiences and practices of several established UX professionals and companies working in an agile environment. He discusses Kent Beck’s story-mapping ideas, bringing in his views on simplicity and acceptance criteria.

This is key takeaway # 3:

Stories get their name from how they are supposed to be used, not from what you are writing down

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

At the beginning of the book we saw the vacation-photos story. During the 3 C’s process he 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 people who blindly fill out templates, calling them “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.”

The story information is actually in people’s minds, and it’s possible that everyone has different thoughts about the same story or activity.

Key takeaway #4:

Bake stories like a cake

Jeff now spends time explaining how to ‘bake stories like a cake’.

  1. If the story describes a solution that’s too expensive, consider a different solution that helps you reach the goal
  2. If the story describes a solution that’s affordable but big, break it into smaller parts that will allow you to evaluate and see progress sooner (cupcakes)
  3. Luke Hohman — “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 is enough to taste and leave everyone looking forward to the rest of the cake.

The book then talks about breaking down stories like rocks and is key takeaway #5.

Break stories down like rocks

Think of an opportunity or feature idea as a big rock, and keep breaking things down just like if you were to hit a big rock with a hammer you would get small rocks. The hammer in this case, is the technique of user story mapping.

  1. A right sized story from a user’s perspective is one that fulfils a need
  2. A right sized story from a development team’s perspective is one that just takes a few days to build and test
  3. A right size story from a business perspective is one that helps business achieve business outcome

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

Points of Attention While Building Story Maps

This last 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.

Jeff also talks about the concept of using a triad or the 3 Amigos for discovery sprints, in a dual track development model as well.

Finally, 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”

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