Jeff Patton - User Story Mapping: Discover the Whole Story, Build the Right Product

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.

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 chunksstoriesenable much more visibility into the progress of a development project. When a product is built story-by-story, with each storys 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 usersno longer do they have to wait a year or more to see what the development teams been up to.

But this chunking has some negative consequences. One of these is that its easy to lose the big picture of what a software system should do. You can end up with a jumble of pieces that dont fit into a coherent whole. Or you can end up building a system that isnt really helpful to the users, because youve missed the essence of whats 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.

Thats it, reallythe 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 theyve learned that technique from workshops run by Jeff, because hes 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 isnt 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 its 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 softwareleading 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 processwhich is the most critical part of software development itself.

In Mary Shelleys 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.

Its entirely reasonable that programmers build software one feature at a time. Thats 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 practicedesign and developmentcollaborate, 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 worktheir pace, language, and rhythmis 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.

Jeffs 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 wont get you to a product that users love. On the other hand, so many times we have seen good designs, well documented, given to developersAgile or notwho manage to kill the essence of the design in the process of implementation.

Pattons story mapping approach is the bridge over this chasm. Interaction design is all about finding the users truth and telling it as a narrative. Software development is all about breaking those narratives into tiny, functional chunks and implementing and integrating them. Its 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 users stories, the design retains its narrative structure yet can still be deconstructed for effective implementation. The designers story, which is a formalized version of the users 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. Its ridiculously hard to make such software fun to use and easy to learn.