"User Story Mapping" Reading Notes

Introduction

User story mapping, as an effective requirements tool, is increasingly being applied in development practices. This book focuses on user story mapping and emphasizes a collaborative communication approach to comprehensively understand user needs. The topics covered include:

• How to articulate user needs through story mapping
• How to decompose and optimize requirements
• How to actively learn from experiences through team collaboration
• Gaining insights into user needs to develop truly valuable, small, and beautiful products and services

Key Points

1. User story mapping is meant to establish a consensus.
2. User stories should be reasonably split.
3. A minimum viable product is the smallest scale experiment conducted to validate hypotheses.
4. Validated learning involves creating prototypes with a certain level of fidelity.

Excerpts

Chapter 0: Must Read Before Use

1. Good user stories discuss who they are for and why they are being created, not just what they are.
2. Only by meeting the needs of customers and users can a company achieve its own goals.
3. Keep the following points in mind:
   • User stories are not just another way to write requirements; telling user stories, with a combination of text and images, assists in discussions and serves as a mechanism for building consensus.
   • User stories are not requirements; they are discussions about problem solutions aimed at addressing company, customer, and user issues, with the goal of reaching a consensus on the features to be developed.
   • Your job is not to develop more features faster, but to maximize the outcomes and impact of the features you invest effort in developing.

Chapter 1: Product Overview

1. User story mapping involves breaking down while telling the big story.
2. Note-taking while telling: As you tell the story, concretize your thoughts by writing on cards or sticky notes.
3. In software development, the features we want to develop far exceed the time and money we can afford. Therefore, the goal of software development has never been to develop all features, but to develop as few as possible.
4. Using cards can enhance the level of communication understanding.
5. User story mapping can help identify pitfalls in product ideas early on.
6. "Broad thinking, detailed focus." Before getting lost in details, walk through the entire story. Focus on the overall story without getting bogged down in details too soon.
7. User story mapping organizes communication content through effective communication in the form of a map. Most people focus on the map's structural part, where the steps of telling the big story go from left to right, and the gradual refinement goes from top to bottom. However, the most critical part is the product concept framework, with more background information placed around the map, including product goals and customer and user information. If you post the story map on the wall, you'll find that placing user interface sketches and other notes around the map is a good idea.

Chapter 2: Planning for Less Development

1. A product release map that spans various teams can help teams visualize dependencies.
2. During the process of building user story maps, teams can identify overlooked parts in advance. The scope of requirements does not expand; rather, our understanding of the requirements deepens.
3. Focus on expected outcomes outside the system to determine what features are needed within the system.
4. Focus on outcomes, i.e., what users can use and perceive after the product is released; the release plan should be outcome-oriented.
5. Focus on specific target outcomes, which is the secret to prioritizing development work.
6. A minimum viable product is not a product that users only use in specific scenarios, nor is it a product released only to highly tolerant users; it refers to software that can survive independently, the smallest product release that can achieve expected outcomes, and the smallest scale experiment conducted to validate hypotheses.

Chapter 3: Planning for Faster Learning

1. The first discussion of product stories should focus on how to visualize product opportunities.
2. Hand-drawn wireframes and high-fidelity prototypes can help you visualize solutions.
3. Treat each release as an experiment, focusing on what you want to learn.

Chapter 4: Planning for Timely Releases

1. The ultimate goal of building story maps: all team members reach a shared understanding, can identify issues and improvement points in design proposals, and estimate how much development time is needed.
2. The most reliable estimates come from engineers who truly understand what they are estimating.
3. Continuously assess and refine your work using iterative thinking. Use incremental thinking to add value.

Chapter 5: How to Create Story Maps

1. User tasks are the basic modules for building story maps.
2. Using the concept of goal hierarchy can help summarize small tasks or break down large tasks.
3. Story maps are organized through a left-to-right narrative flow, which is the most natural way for people to tell stories.
4. Details, alternatives, variations, and exceptions form the main body of the story map.
5. Activities make up the backbone of the story map.
6. Use decomposition to identify all tasks and details related to specific outcomes.

Chapter 6: The Story of User Stories

1. The best solutions come from collaboration between those who need to solve problems and those who have the capability to solve them.
2. User stories are named not for how to write better user stories, but for how to better use them in writing.
3. We discuss user stories together, striving to reach a shared understanding of the problems to be solved and working hard to find the best solutions.

Chapter 7: How to Tell Stories Better

1. Template format is not the only element of user stories.
2. Checklist for enhancing discussion effectiveness:
   • Discuss user roles
   • Discuss the features to be developed
   • Discuss the reasons
   • Discuss things outside the software
   • Discuss exceptions
   • Discuss problems and hypotheses
   • Discuss better solutions
   • Discuss how to implement the solutions
   • Discuss the development cycle

Chapter 8: Don’t Write Everything on the Cards

1. Each user story includes various discussions between different roles.
2. During video conferences, keep the camera focused on the wall with sticky notes.
3. Remote collaboration requires tools that allow everyone to see and interact with the cards simultaneously.
4. Using tools to save text, images, and videos can help recover the details of the discussion context.
5. Use tools to arrange development order, track, and analyze the development process.

Chapter 9: Cards Are Just the Beginning

1. Handing over all the details of the story to developers to organize development work is not feasible; do not do this.
2. Validated learning is more valuable than working software.
3. Try to drive everything through user stories, whether software or otherwise.

Chapter 10: Making Products Is Like Baking a Cake

1. If the solution described in the story is too expensive, consider alternatives.
2. If the solution described in the story fits the budget but is still large, breaking it down into smaller pieces can help you evaluate the product and manage progress more timely.
3. Do not cut the big story into a large plan. Cut the big story into smaller pieces and make small plans.

Chapter 11: Fragmented Actions

1. From the user's perspective, a story of appropriate size is one that can meet a specific need.
2. From the development team's perspective, a story of appropriate size is one that can be completed in a few days of development and testing.
3. From a business perspective, a story of appropriate size is one that helps achieve business goals.
4. Use opportunity discussions to reach a consensus on whether the problem is worth solving, ultimately making a decision to proceed or cancel.
5. Through exploration and dialogue, strive to find the smallest, viable solution.
6. Discuss details through deep-dive story workshops, break down stories, and reach a consensus on what we will develop.
7. When starting to develop product details, provide feedback on the software being developed through dialogue.
8. Regularly reflect on product quality, work plans, and work methods.
9. Use meaningful working software modules to test customers and users, and learn from them.
10. For stakeholders within the organization, the project's progress and completion quality should remain continuously visible.
11. Use metrics and direct user contact to truly understand whether the results meet expectations.

Chapter 12: Who Is the Fragmentation Leader?

1. Expecting a product owner to write all stories and conduct all story dialogues is clearly unfeasible.
2. A good product development team has a product owner as a key leader who can align the product and the entire team throughout the process. Another poor anti-pattern is committee design, where everyone has equal say and can participate in development decisions; in a committee, when we only have the time and resources to do one thing, we often tend to compromise.
3. A small, cross-functional team led by the product owner carefully arranges product exploration work. The ideal size for the exploration team is 2 to 4 people, which is the size for table conversations, allowing everyone to quickly build consensus.
4. Assemble a core team to assist the product owner, including user experience experts, design experts, and technical experts.
5. As a product owner, balance the ideas of other stakeholders and play the role of a producer, helping them achieve success.

Chapter 13: Starting from Opportunities

1. For each opportunity, discuss the following five aspects:
   • Who are the targets?
   • What problem are we solving?
   • What is our concept?
   • Why?
   • Size
2. Use maps created for existing products to discover opportunities or consider current opportunities based on the background of existing products.

Chapter 14: Building Consensus Through Exploration

1. The four core steps of exploration:
   • Organize ideas from a business perspective
   • Understand customers and users, clarifying how to help them
   • Present your solutions
   • Simplify and plan to find the minimal viable solution and its specific development approach
2. Create lightweight user personas together to build consensus and empathy within the team.
3. Visualize the user interface to strive for consensus on the solution.
4. Prioritize specific business goals, customers, and users, then prioritize their goals, and finally the features.

Chapter 15: Conducting Validated Learning Through Exploration

1. Subconsciously brainstorm several possible solutions to customer and user problems.
2. Create simple prototypes for exploration to arrive at the best solutions. Develop prototypes with a certain level of fidelity so that users and customers can evaluate whether the solutions truly address their problems.
3. Show the solutions to potential buyers or users of the product; do not expect them to succeed right away, but continuously iterate and improve.
4. In lean startups, not learning anything is often the biggest failure. In lean startup methods, development means conducting the smallest viable experiments as much as possible.

Chapter 16: Refining, Defining, and Developing

1. In traditional software processes, what is "checked off" is called "bad requirements." But in agile processes, this is merely learning and iterative improvement.
2. In each development cycle, find out which story should be invested in next on the map. Bring these stories into the final best dialogue of the story workshop.

Chapter 17: Stories Are Like "Planetary Battle Machines"

1. Decompose stories progressively rather than completing them all at once. In every story discussion and decomposition phase, keep the goal in mind.
2. Story maps serve to facilitate dialogues about user and product ideas; a good rule of thumb is that if there is no need for discussion, there is no need to draw a user map.

Chapter 18: How to Learn After Development Completion

1. Software is never truly finished.
2. Results are never guaranteed.
3. Improvements after release are the most valuable.

Author Bio

Jeff Patton, over his more than twenty years of experience, has learned that while there is not just one correct way to design and build software, there are countless wrong ways.

Jeff has fifteen years of rich product experience, having worked on online aircraft parts reservations and electronic medical records, mainly helping clients organize and improve their work methods. While many development processes focus solely on delivery speed and efficiency, Jeff has long been balancing the delivery of software products that provide extraordinary value and achieve market success.

Since joining an early extreme programming team in 2000, Jeff has focused on agile methods, particularly specializing in integrating effective user experience design and product management practices into solid engineering practices.

Currently, Jeff serves as an independent consultant, agile process coach, product design process coach, and mentor. His articles, essays, and presentations on various topics in agile product management can be found at agileproductdesign.com and Alistair Cockburn's Crystal Clear. Jeff is the founder and coordinator of the Agile Usability Yahoo discussion group, a columnist for StickyMinds.com and IEEE Software, a Certified Scrum Trainer (CST), and the recipient of the Agile Alliance 2007 Gordon Pask Award.