Seed User Stories

Stories

Story Map Product Principles Personas

User Story Map

A User Story Map is a collaborative tool used to visually organize user stories to build a product around the user’s journey. Here’s a summary of its purpose, structure, and key benefits, plus some pr

Foreword by Martin Foller

One of the beneficial consequences of the rise of Agile software development is the notion of splitting up large sets of requirements into smaller chunks. These chunks—stories—enable much more visibility into the progress of a development project. When a product is built story-by-story, with each story’s implementation fully integrated into the software product, everyone can see the product grow. By using stories that make sense to users, developers can steer the project by determining which stories to build next. This greater visibility helps encourage greater participation from users—no longer do they have to wait a year or more to see what the development team’s been up to.

But this chunking has some negative consequences. One of these is that it’s easy to lose the big picture of what a software system should do. You can end up with a jumble of pieces that don’t fit into a coherent whole. Or you can end up building a system that isn’t really helpful to the users, because you’ve missed the essence of what’s needed by getting lost in the details.

Story mapping is a technique that provides the big picture that a pile of stories so often misses.

That’s it, really—the description of this book in a single sentence. And that sentence carries with it the promise of a lot of value. A big picture helps communicate effectively with users, it helps everyone involved avoid building unnecessary features, and it provides an orientation for a coherent user experience. When I talk to my colleagues at ThoughtWorks about what they do to develop their stories, story mapping regularly comes up as a core technique. Often they’ve learned that technique from workshops run by Jeff, because he’s the one who developed the technique and can best communicate it. This book allows more people to understand this technique directly from its source.

But this isn’t just a book for people who have something like “business analyst” on their business card or online profile. Perhaps the biggest disausppointment for me in the decade of the adoption of Agile methods is the way that many programmers see stories as a one-way communication from analysts to them. Right from the beginning, stories were supposed to spark conversations. If you really want to come up with effective software to support an activity, then you need to look to those who build software as a vital source of ideas for its capabilities, because it’s programmers who know best what software can do. Programmers need to understand what their users are trying to achieve and should collaborate in building the stories that capture those users’ needs. A programmer who understands story mapping can better see the broader user context and can participate in framing the software—leading to a better job.

When Kent Beck (who originated the notion of a “story”) developed his ideas on software development, he called out communication as a key value of effective teams. Stories are the building blocks of communication between developers and those who use their work. Story maps organize and structure these building blocks, and thus enhance this communication process—which is the most critical part of software development itself.

Foreword by Alan Cooper

In Mary Shelley’s famous science-fiction novel, Frankenstein, the mad Doctor Frankenstein builds a creature from disparate pieces of dead humans and brings the creature to life with the then-new technology of electricity. Of course, we know that this is not actually possible. You cannot create life by sewing together random body parts.

Yet this is what software developers attempt to do all the time. They add good features to software, one at a time, and then wonder why few users love their product. The heart of the conundrum is that developers are using their construction method as a design tool, but the two are not interchangeable.

It’s entirely reasonable that programmers build software one feature at a time. That’s a perfectly good strategy, proven over the years. What has also been proven over the years is that, when used as a method for designing the behavior and scope of a digital product, one-feature-at-a-time yields a Frankenstein monster of a program.

While they are intimately related, the practice of designing software behavior and the practice of building that software are distinctly different, and are typically performed by different people with different skill sets. The many hours that interaction designers spend observing users and mapping behavior patterns would drive most programmers batty. Conversely, the hours of sweating over algorithms are too solitary for most designers.

But when the two strains of practice—design and development—collaborate, the work becomes electric and has the potential to create a living, breathing product. Teamwork breathes life into the monster and makes people love it.

While the idea of collaboration is neither new nor particularly insightful, it is actually very difficult to do effectively. The way that developers work—their pace, language, and rhythm—is quite different from that of interaction designers.

Practitioners in each of the two fields are strong, capable, and internally well disciplined, yet they share a single, common weakness. It is really hard to express a design problem in programming terms, and it is equally hard to express a development problem in design terms. The two sister disciplines lack a common tongue. And that junction between the two disciplines is precisely where Jeff Patton lives.

Jeff’s method of story mapping makes sense to developers, and it makes equal sense to designers. Story mapping is the Rosetta Stone for our digital age.

Despite protestations to the contrary, Agile development is not a very useful design tool. It is a way of thinking about development that is design-friendly, which is a very good thing, but by itself it won’t get you to a product that users love. On the other hand, so many times we have seen good designs, well documented, given to developers—Agile or not—who manage to kill the essence of the design in the process of implementation.

Patton’s story mapping approach is the bridge over this chasm. Interaction design is all about finding the user’s truth and telling it as a narrative. Software development is all about breaking those narratives into tiny, functional chunks and implementing and integrating them. It’s so ridiculously easy for the essence of the narrative to slip away during this complex process. Yes, the functions are implemented, but the patient dies on the operating room table.

By mapping out the user’s stories, the design retains its narrative structure yet can still be deconstructed for effective implementation. The designer’s story, which is a formalized version of the user’s story, remains intact throughout the development.

The conventional corporate world has proven that it is nearly impossible for a team of two or three hundred people to build a product that people love. Meanwhile the startup community has proven that a team of four or five people can build small products that people love, but even these little products eventually grow big and lose their spark. The challenge we face is creating big software that people love. Big software serves large audiences doing complex, commercially viable jobs. It’s ridiculously hard to make such software fun to use and easy to learn.

The only way we are going to build big software that is not a Frankenstein monster is by learning how to integrate the disciplines of software design and development. Nobody knows how to do that better than Jeff Patton.

Introduction

Building a map is dead simple. Working together with others, I’ll tell the story of a product, writing each big step the users take in the story on sticky notes in a left-to-right flow. Then, we’ll go back and talk about the details of each step, and write those details down on sticky notes and place them vertically under each step. The result is a simple grid-like structure that tells a story from left to right, and breaks it into details from top to bottom. It’s fun and fast. And those details make a better backlog of stories for our Agile development projects.

Building Shared Understanding

If we get together and talk you can te

User Stories

Writing small titles in cards (stories) and discussing upon them was a great way of prioritizing, taking into account that one card could take hours or even days of development. User Story Mapping Book

Stories aren't a written form of requirements; telling stories through collaboration with words and pictures is a mechanism that builds shared understanding.
Stories aren't the requirements; they're discussions about solving problems for our organization, our customers, and our users that lead to agreements on what to build.
Your job isn't to build more software faster: it's to maximize the outcome and impact you get from what you choose to build.
Minimize output, and maximize outcome and impact.

How to define Outcome

But, while it’s necessary, the output isn’t the real point; it’s not the output that we really wanted. It’s what comes after as a result of that. It’s called outcome. Outcome is what happens when things come out—that’s why it’s called that—and it’s difficult because we don’t get to measure outcome until things do come out. And we don’t measure outcome by the number of features delivered, or what people have the capability to now do. 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.[2] That’s it. You’ve changed the world.

Patton, Jeff. User Story Mapping: Discover the Whole Story, Build the Right Product . O'Reilly Media. Kindle Edition.

The Big Picture.
Telling Stories, Not Writing Stories.
Stories get their name from how they should be used, not what should we written.
Plan to Build Less.
Plan to Learn Faster.
Plan to Finish on Time.
You Already Know How
The Real Story About Stories
Telling Better Stories.
It's Not All on the Card.
The Card is Just the Beginning.
Bake Stories Like Cake
Rock Breaking.
Rock Breakers.
Start with Opportunities.
Using Discovery to Build Shared Understanding
Using Discovery for Validated Learning
Refine, Define and Build
Stories Are Actually Asteroids
Learn from Everything you Build

Frame the problem. Who is it for, and why are we building it?
Map the big picture. Focus on breadth, not depth. Go a mile wide and an inch deep (or a kilometer wide and a centimeter deep, for my friends in the rest of the world). If you don’t have a clear solution in mind, or even if you think you do, try mapping the world as it is today, including pains and joys your users have.
Explore. Go deep and talk about other types of users and people, how else they might do things, and the kinds of things that can (and likely will) go wrong. For extra credit, sketch, prototype, test, and refine solution ideas—changing and refining the map as you go.
Slice out a release strategy. Remember: there’s always too much to build. Focus on what you’re trying to achieve for your business, and on the people your product will serve. Slice away what’s not needed to reveal minimum solutions that both delight people and help your organization reach its goals.
Slice out a learning strategy. You may have identified what you think is a minimum viable solution, but remember that it’s a hypothesis until you prove otherwise. Use the map and discussion to help you find your biggest risks. Slice the map into even smaller minimum viable product experiments that you can place in front of a subset of your users to learn what’s really valuable to them.
Slice out a development strategy. If you’ve sliced away everything you don’t need to deliver, you’ll be left with what you do need. Now slice your minimum viable solution into the parts you’d like to build earlier and later. Focus on building things early that help you learn to spot technical issues and development risks sooner.

Future Product

The current state of the User Story Map is not what we are going to build. It is how we imagine Today the Product from the Future. However, having a clear path of the Future Product allows us to define better the software we are building today. Also, as we build today we keep on changing the future dynamically. The Future Product is in constant change: features are removed and added, their priority is changed and they get defined in detail. As we learn from Today we defined the User Stories of the future, hammering down the product. Once a User Story is well enough defined, and has gone through weeks surviving as a to be develop feature that will benefit our users, we will start developing it.