Author: Jeff Patton
Audience: Agile practitioners
Reviewer: Alex Armstrong
Subtitled "Discover the Whole Story, Build the Right Product", does this book provide practical help?
If you are a reader who goes straight to page 1 you may miss the fact that this is book has three forewords. The first comes from Martin Fowler and includes the sentence:
Story mapping is a technique that provides the big picture that a pile of stories so often misses.
In the third foreword Marty Cagan tell readers that the book is about much more than the "powerful yet simple technique" of user story mapping and that it:
"gets to the heart about how teams collaborate, communicate and ultimately come up with good stuff to build".
This foreword is itself much more than a foreword and has a long section that itemizes important differences between strong product teams and weak teams.
Next comes a Preface in which Jeff Patton opens with:
This book was supposed to be a small thing … a pamphlet really.
In the event it has turned into an 18 chapter book plus a Read Me First that replaces an Introduction. Patton explains that as a reader he usually skips the introduction which is why he insists that readers pay attention to this pre-amble which clearly states the main points you are expected to take away from the book including
- The goal of using stories isn't to write better stories
- The goal of product development isn't to make products
Confused - well we have finally arrived at Chapter 1.
The first four chapters of the book give an overview of story mapping, In Chapter 1: The Big Picture we quickly skip past the idea that story mapping is a way to work with user stories as the are used in Agile processes. One key idea in this chapter is that you don't write stories – instead you tell them.
Chapter 2's title conveys the message Plan to Build Less and it explores the idea of a Minimum Viable Product. As in the previous chapter it relies on case studies to illustrate the points it makes. The next two chapters, with the titles Plan to Learn Faster and Plan to Finish on Time introduce more case studies. These are brought to lie with photos and illustrations which, together with the author's conversational style make for an easy read.
Chapter 5 has a change of pace and tactic. It challenges you to:
Grab a pad of sticky notes and a pen and follow along with me.
The story you are expected to work with for this exercise is your morning routine, but its intention is to help you learn the key concepts of creating a story map.
Chapters 6 to 12 give a more detailed view of story mapping, starting with Kent Beck's initial revelation of the need to get together and talk about the problem that software is supposed to solve. Patton goes on to discuss Ron Jefferies' 3 Cs – Card, Conversation, Confirmation. Next he looks at story templates which provide a simple structure on which to base a user story and then provides a checklist of what you should be talking about.
As this section progresses the process of story mapping gets more and more detailed until in Chapter 12: Rock Breakers Patton admits:
For an idea that at its core is simple, this whole story thing has gotten terribly messy. If anyone told you software development - or any product development, for that matter - was easy, they were lying.
and goes on to explain:
Stories are many things at once. ... Working with stories is a continuous process of conversation and discussion to break them down from big things to small things.
The book gets very detailed in its last few chapters, but the good news is that it becomes both more prescriptive with steps to work through and more case history material contributed by people using the story mapping approach. Chapter 13 tells you to Start with Opportunities – ideas that you believe will solve a problem and Chapter 14 looks at product backlog. The next chapter comes as a bit of a shock by starting with the words “I've misled you, sort of” and it goes on to discuss design thinking and reminds you of the need for testing.
Chapter 16: Refine, Define and Build returns to cards and conversation but by this point in the book the conversations are now talking place in workshops and being incorporated into agile development. With the title Stories Are Actually Like Asteriods Chapter 17 tells you to break down stories and reassemble them and the final chapter has advice you'll meet often in the context of Agile, Learn from Everything you Build.
You probably won't be surprised to find an epilogue - a one-page with the title The End,or Is It?
OK, there are some useful messages in this book, but could they have been conveyed more succinctly? Perhaps, but if you like Patton's laid back style you'll enjoy his extended exposition. Not for those in a hurry, but rather for those prepared to consider all angles.