User Story Mapping Read online

  User Story Mapping

  Jeff Patton

  Dedication

  For Stacy, Grace, and Zoe who are my biggest supporters and make all my effort worthwhile.

  And in memory of Luke Barrett, a dear colleague and mentor of mine. Luke made a difference in my life as he did countless others.

  Foreword by Martin Fowler

  Martin Fowler

  June 18, 2014

  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 disappointment 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

  Alan Cooper

  June 17, 2014

  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.

  Foreword by Marty Cagan

  Mar
ty Cagan

  June 18, 2014

  I’ve had the extremely good fortune to be able to work with many of the very best technology product teams in the world. People creating the products you use and love every day. Teams that are literally changing the world.

  I’ve also been brought in to try to help companies that are not doing so well. Startups racing to get some traction before the money runs out. Larger companies struggling to replicate their early innovation. Teams failing to continuously add value to their business. Leaders frustrated with how long it takes to go from idea to reality. Engineers exasperated with their product owners.

  What I’ve learned is that there is a profound difference between how the very best product companies create technology products, and the rest. And I don’t mean minor differences. I mean everything from how leaders behave to the level of empowerment of teams; to the way teams work together; to how the organization thinks about funding, staffing, and producing products; to the culture; to how product, design, and engineering collaborate to discover effective solutions for their customers.

  This book is titled User Story Mapping, but you’ll soon see it is about much more than this powerful yet simple technique. This book gets to the heart about how teams collaborate, communicate, and ultimately come up with good stuff to build.

  Many of you have never had a chance to see up close how a strong product team operates. All you may know is what you’ve seen at your company or where you’ve worked before. So what I’d like to do here is to try to give you a flavor of just how different the best teams are from the rest.

  With a grateful nod to Ben Horowitz’s Good Product Manager, Bad Product Manager, here’s a glimpse into some of the important differences between strong product teams and weak teams:

  Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries.

  Good teams get their inspiration and product ideas from their scorecard KPIs, from observing customers struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers.

  Good teams understand who their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that not only work for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders.

  Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps.

  Good teams love to have brainstorming discussions with smart thought leaders from across the company. Bad teams get offended when someone outside their team dares to suggest they do something.

  Good teams have product, design, and engineering sit side-by-side, and embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their respective functional areas, and ask that others make requests for their services in the form of documents and scheduling meetings.

  Good teams are constantly trying out new ideas in order to innovate, but doing so in ways that protect the revenue and the brand. Bad teams are still waiting for permission to run a test.

  Good teams insist they have the skill sets necessary to create winning products, such as strong interaction design. Bad teams don’t even know what interaction designers are.

  Good teams ensure that their engineers have time to try out the discovery prototypes every day so that they can contribute their thoughts on how to make the product better. Bad teams show the prototypes to the engineers during sprint planning so they can estimate.

  Good teams engage directly with end users and customers every week to better understand their customers, and to see the customer’s response to their latest ideas. Bad teams think they are the customer.

  Good teams know that many of their favorite ideas won’t end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome. Bad teams just build what’s on the roadmap and are satisfied with meeting dates and ensuring quality.

  Good teams understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed comes from the right techniques and not forced labor. Bad teams complain they are slow because their colleagues are not working hard enough.

  Good teams make high-integrity commitments after they’ve evaluated the request and ensured they have a viable solution that will actually work for the customer and the business. Bad teams complain about being a sales-driven company.

  Good teams instrument their work so that they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consider analytics and reporting a “nice to have.”

  Good teams integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers. Bad teams test manually at the end of a painful integration phase and then release everything at once.

  Good teams obsess over their reference customers. Bad teams obsess over competitors.

  Good teams celebrate when they achieve a significant impact to the business KPIs. Bad teams celebrate when they finally release something.

  I realize you might be wondering what all this has to do with story maps. I think you’ll be surprised. And that’s precisely why I am a fan of story maps.

  I have met only a few Agile experts whom I consider qualified to actually help a serious product team raise its game to the level its company needs and deserves. Jeff Patton is one of them. I have observed him working hands on in the trenches with teams in the midst of product discovery. I introduce him into companies because he is effective. Teams love him because he is knowledgeable yet humble.

  The days of product managers gathering up and documenting requirements, designers scrambling just to put some lipstick on the product, and engineers sheltered in the basement, coding, are long gone for the best teams. And it’s time they are gone for your team, too.

  Preface

  Live in it, swim in it, laugh in it, love in it / Removes embarrassing stains from contour sheets, that’s right / And it entertains visiting relatives, it turns a sandwich into a banquet.

  — Tom Waits, “Step Right Up”

  This book was supposed to be a small thing…a pamphlet, really.

  I set out to write about a simple practice I called story mapping. I, and lots of other folks, build simple maps to help us work together with others and to imagine the experience of using a product.

  Story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product.

  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.

  How complicated could writing a book about this be?

  But it turns out that even the simple things can be pretty sophisticated. And writing about why you would want to build a story map, what’s going on when you build one, and all the different ways you can use one took me a lot of pages. There was more to this simple practice than I thought.

  If you’re using an Agile development process, you’re likely filling backlogs with user stories. I’d assumed that since stories were such a common practice, it’d be a waste of time for me to write about them in this book. But I was wrong. In the decade and a hal
f since stories were first described by Kent Beck, they’re more popular — and more misunderstood and misused — than ever before. That makes me sad. And, what’s more, it kills all the benefit we get from story mapping.

  So, in this book, I would like to correct as many big misconceptions as I can about stories and the way they’re used in Agile and Lean software development. That’s why, in the words of Tom Waits, I’ve turned this “sandwich into a banquet.”

  Why Me?

  I like making things. What motivates me is the joy I get from creating a piece of software and seeing people use it and benefit from it. I’m a reluctant methodologist. I found I needed to learn how process and practice work to get better at them. I’m only now learning after 20-plus years in software development how to teach what I’ve learned. And I know that what I teach is a moving target. What I understand changes every week. How best to explain it changes almost as fast. All that’s kept me from writing a book for years.

  But it’s time.

  Stories and story maps are such a good idea. They’ve benefited so many people. They’ve made their lives better, and the products they build better. But while some people’s lives are getting better, there are more people struggling with stories than ever before. I want to help stop that.

  This book is something I can make to help. And, if it improves the work lives of even a few, I’ll celebrate.

  This Book Is for You If You’re Struggling with Stories