User Story Mapping
User Story Mapping: Discover the Whole Story, Build the Right Product
User Story Mapping is a fantastic book that discusses the realities of product development and takes a refreshingly human perspective on how software is created. Although there is sufficient process and detailed advice, the central themes of the book portray the actual challenges of working with other people to bring software to a user community. Patton presents all his ideas and frameworks in a very direct and reality-based context. There are no process-bound or methodological pronouncements here–reading the book is like sitting down with an experienced peer and “telling it like it is.” Patton takes a very essentialist and commonsense approach to an activity which has suffered from a lot of complexity and formality.
How to create good user stories
We can’t understand each other by exchanging documents. We can’t tell if we’ve built the right thing until we see it.
User stories encapsulate an aspect of a product which is to be developed. The intent of a “story” is literally for one person to tell a story to another. The goal of storytelling isn’t to tell the story in a specific format or tell a story the right way, it’s to communicate with someone. In the case of software development, the stories are meant to be spoken in part of a conversation. If humans can’t use the story to gain and understanding of the goal to be achieved, then the story, no matter how well written, has not succeeded.
Building Shared Understanding
The goal of using stories isn’t to write better stories
User stories and other forms of documentation should be used to foster shared understanding of user goals and interaction. There is no perfect format for product documentation and attempting to find just the right form for documentation will detract from the goal of shared understanding among the team. Patton begins the book with the “phone game” analogy where the meaning of an original message is lost in translation. Stories and other requirement formats are simply there to help the team discuss, elaborate, question, and develop a common vision of the goal.
If you’re using stories…and not talking together using words and pictures you’re doing it wrong
Patton says stories should be like vacation photos: they give you a sense of what’s going on, but without explanation and elaboration, they don’t tell you everything you need to know. Software development can’t be confined to a single artifact or format because the problem space is so diverse. Tables, diagrams, flows, charts, pictures, renderings, and other media each tell a part of the overall story.
Document to remember
what’s most important isn’t what’s written down–it’s what we remember when we read it
A story-driven process will necessarily require many types of documents and diagrams, each of which serves to continue the conversation and discovery on the path to increased clarity on objectives. There is no single format or media which will be sufficient to describe the product. Patton advises using sticky notes, photos, and videos to illuminate different aspects of the product under development. No matter how many documents are produced, if what people have in their heads does not match, all is for naught.
Changing the world
We measure what people actually do differently to reach their goals as a consequence of what you’ve built, and most important, whether you’ve made their lives better.
Product teams should think in terms of outcomes, not outputs. Thinking about how the world is now and how you want it to be in the future generates the outcomes that the team should aim at. Patton points out that software is not the end goal. The real outcome is change in the world, not the programs and components that are produced by the team. Because of this, the conversations the team has about stories should center on “who and why, not just what.”
Choose carefully
your job is to minimize output and maximize outcome and impact
Patton exhorts us to “build less”. No business can satisfy every customer and no business has the resources to chase after every opportunity. Focusing on outputs ensures the team is solving the wrong type of problem; focusing on impact means the team is trying to change the world.
