5min books review #6

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

Value for money

9/10

Ebook or Bookshelf?

This deserves a place on your bookshelf.

Year, Price, Pages, Cover design

2014 by O’Reilly Media; Euro 26,49; 259 pages (278 pages with Acknowledgments, References, Index, About the Author), Paperback

Cover design by Ellie Volckhausen, Illustration by Rebecca Demarest, Interior design by David Futato. Good paper quality and reading experience

5 sentences about the book

• Rethink your expectations of this book: it is not a manual on “how to write user story”, but a broad compendium of knowledge about software product management
• It is not one-time reading, but hand-book you reach for again and again to remind yourself of the basic principles
• If you have prejudices against O’Reilly publisher, then this book is an opportunity to get rid of them
• The narrator guides you with special care. He is whispering secrets to your ear and he is telling funny stories from everyday life. By the very end, you have a feeling that you’ve known Jeff Patton for a very long time. You may want to invite him for drinks and discuss some parts of the book. (The narrator’s voice reminds me of a character in Ridley Scott’s movie — A Good Year (2006). His name is Henry Skinner and he’s an uncle of our protagonist)
• A unique book, an extraordinary book in the best sense of the word

What did I learn?

• I understand better what user story mapping is
• I know how to organize the workshop based on the conversation to get the big picture and common understanding of what to build
• You will get several hints, useful tips and checklists like 1. Steps how to build a big picture; 2. Six simple steps for story mapping; 3. A checklist of what to talk about during the conversation; 4. Plan to build less; 5. Plan to build on time; 6. Plan to learn faster; etc.
• I consider User Story Mapping as my top 3 books about product management on my list

What was missing?

• The second half of the book talks about the user story mapping in the context of the discovery process, product backlog, backlog refinement, design thinking, product review, product release and retrospective. I had a strong impression that the narration lost tempo. Everything was fine until the author was focused on explaining what user story mapping is and how to use it. I don’t say that’s bad, but I didn’t read the second half with such focus, involvement and speed.

Favourite quotes:

“You and everyone else will learn that stories aren’t a way to write better requirements, but a way to organize and have better conversations.” xxv

“If you get nothing else from this book, remember these things:

• 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 organisation, 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 ” xliv

“Stories get their name from how they should be used, not what should be written.” 3

“The original idea of stories was a simple one. It turned our focus away from shared documents and toward shared understanding” 4

“At the top of the maps is the backbone, which sometimes has a couple of different levels. You might start with the basic flow of the story, which is one level. But, when it gets really long, it’s useful to go up one more level to summarize things further.” 23

“Every time we do this we find holes. We find things that we thought another team should be taking care of, but it didn’t know.” 25

“Eric is part of a team that took those ideas and ran with them. That’s what product owners do. If you thought they were always acting on their own great ideas, well, you’re wrong. One of the hard parts of being a product owner is taking ownership of someone else’s idea and helping to make it successful, or proving that it isn’t likely to be. The best product owners, like Eric, help their entire team take ownership of the product.” 38

“But Eric knows his job is to minimize the amount he builds and still keep people happy” 41

“You’ve already learned the two most important things that make stories work:

• Use storytelling with words and pictures to build a shared understanding
• Don’t just talk about what to build: talk about who will use it and why so you can minimize output and maximize outcome” 84

“Stories get their name not from how they’re supposed to be written, but from how they’re supposed to be used” 91

“If you’re not getting together to have rich discussions about your stories, then you’re not really using stories” 92

“Story conversations are about working together to arrive at the best solution to a problem we both understand” 94

“It doesn’t need to be written in a template to be considered a story” 102

“For me, the story template works a bit like learning the snowplow. Use it to write the descriptions of your first stories” 103

“There are many different kinds of conversation with different people for every story” 110

“The most important thing here is that all these people are armed with the same picture in their heads: the picture they build while talking together” 123

“It’ll help everyone’s sanity to separate out two concerns. First: did we build what we agreed to build? And then: if it’s what we agreed to build, now that we see it, should we make some changes?” 125

“The difference between what you think people need and what they really need is the realm of product arrogance” 195

“Remember, our goal is to minimize the amount we build (our output) and maximize the benefit we get from doing it (the outcomes and impact).” 196

“Viable means successful for a specific business strategy, target customer, and users.” 197

“This leads me to one of the biggest mistakes people make, and that’s actually believing their minimal viable solution will be successful” 201

“They didn’t build a full prototype. They did have concerns that their solution would be really usable, and they couldn’t learn that from a comic book. They also had a few technical concerns that would require writing some prototype code to test. But none of that mattered if students didn’t have the problem, and didn’t respond well to their idea.

That smallest possible solution to test is what Lean Startup refers to as a minimum viable product. 214

“The only thing that trumps an executive opinion is cold, hard fact.” 251