Product Backlogs and User Stories
User Story Mapping: Discover the Whole Story, Build the Right Product
Author Jeff Patton walks through the details of creating shared understanding among the product team and managing a backlog focused on business outcomes and changing the world. The bulk of the book is a detailed walkthrough of creating a story map, complete with photos of actual mapping exercises. Patton uses several real-life application examples to illustrate the process and describe how teams handled various challenges. The book covers the details of building the story map and prioritizing stories. In addition to the case studies, there are multiple summaries of the method along with a handful of important principles to keep in mind to guide the story mapping activity. Patton also includes several sections on planning, facilitating, and managing group design activities.
A consistent theme throughout the book is that user stories are just pointers to more in-depth knowledge and conversations about what needs to be built. Don’t spend your time writing the perfect story, spend your time in valuable and continuing conversations with your team.
Outline your idea
The first step to building your product backlog is to frame your concept by asking:
- Why are you building this product or feature?
- What are the benefits of this product or feature for everyone related to it?
- What problems does it solve for its constituents?
Describe your customers and users
Place cards in your story map which describe your users. This will help remind everyone about the profile and needs of the people who will be using the product. Think about their pain points and paint a “day in the life” picture of the people whose lives you are trying to change.
Tell stories from your users’ perspective
Once you know why you’re building the product, what problem it solves, and for whom, the next step is to start telling stories about the product from the perspective of the people who will be using it.
Story mapping helps build shared understanding on the team building the product. Equally importantly, story mapping will surface gaps in the product concept, user experience, and supported interactions. Writing and talking while focused on a shared, visible artifact, will lead the design team to identify flaws in their thinking and opportunities to improve the value and experience.
Patton suggests thinking “a mile wide and an inch deep”–aim first for completeness and coverage and then circle back for details and fine points.
Explore alternatives and exceptions
Patton provides some questions to ask during story writing that help flesh our the entire context and uncommon paths:
- What would make this really awesome?
- What bad or unexpected things might happen at this step?
- What are alternative actions the user might take here?
Identify Product Principles
It’s important to document, discuss, and have available the broader, contextual and aspirational ideas that will guide the development of your product. These could be unique value propositions, design principles, performance goals, competitive positioning, quality concerns, or any special attribute you want your product to embody.
The Flat Backlog trap
Patton warns against flat backlogs with contain a pile of features, ideas, requests, stories, and issues. There is no practical way to get your arms around a flat backlog: use a “backbone” to describe the major flow of stories. Then, decompose each big, combined backbone story into smaller chunks. For large projects which involve several teams, these smaller chunks can be used effectively to identify dependencies and ensure there no missing steps.
Release slices
One of the best, and most useful parts of the book, is the section which describes how to “slice” your story map into releases. Using what Patton calls “target outcomes” allows you to group stories by outcome underneath the larger backbone story elements.
Conversations are one of the best tools for breaking down large stories
He discusses the difference between epics and stories but is not dogmatic about the definition: it’s about size and the team’s comfort with tackling larger items. The right size of a story for development will differ from the right size for the business and for the story map. The term “epic” can be used to mean “that’s too big to even consider” and act as a deflector which diverts a healthy conversation. User story mapping, with its emphasis on conversation and discovery, is a potent antidote to this blocking tactic.
Don’t prioritize features, prioritize outcomes
Thinking about the outcomes you want to achieve is easier than working through a list of interesting and useful functional descriptions. If you’re thinking about the type of behavior change you want to see in the world, assigning value to features and functions will be a more natural process.
Patton breaks down releases into a “see it work”, “make it better”, and “make it releaseable” sequence. This helps with both with slicing up the story map as well as learning. He calls this method a “tracer bullet” which cuts through all major aspects of the feature or product.
Minimum Viable Product
Our goal isn’t to build something; rather, it is to learn if we’re building the right thing.
Patton tackles the MVP debate by focusing on risk reduction and validation: “a minimum viable product is also the smallest thing you can do to prove or disprove an assumption.” An MVP should aim to ferret out uncertainty, known risks, and assumptions, replacing them with validated knowledge.
Watch out for what people say they want
He points out that often the users themselves, the people who are typically asking you for something, often don’t know themselves whether they’d use something or whether something you build will be valuable. Customers should be viewed as development partners and you should “build to learn.”
Patton points out that often the term “requirement” is used to mean “shut up and build what I tell you”, thereby shutting down all conversation. The open conversation around stories is meant to break this toxic pattern. He suggests using cross-functional “discovery teams” to discuss stories to counteract the “client-vendor” antipattern which assumes a one-way information flow.
