User Story Mapping

Discover the Whole Story, Build the Right Product

By: Jeff Patton, Peter Economy - foreword

Narrated by: Roy McCrerey

Length: 8 hrs and 19 mins

Publisher's Summary

User story mapping is a valuable tool for software development, once you understand why and how to use it. This insightful book examines how this often misunderstood technique can help your team stay focused on users and their needs without getting lost in the enthusiasm for individual product features. 

Author Jeff Patton shows you how changeable story maps enable your team to hold better conversations about the project throughout the development process. Your team will learn to come away with a shared understanding of what you’re attempting to build and why. 

• Get a high level view of story mapping, with an exercise to learn key concepts quickly
• Understand how stories really work, and how they come to life in Agile and Lean projects
• Dive into a story’s lifecycle, starting with opportunities and moving deeper into discovery
• Prepare your stories, pay attention while they’re built, and learn from those you convert to working software

©2014 Jeff Patton (P)2020 Upfront Books

Straw man arguments and handwaving

There are some good starting points, and I appreciated the encouragement to visualizing a story map through the use of real cards, but the continuous one-sided thinking and apparent self-contradiction was disappointing.

A main premise of this book is that your team should stop trying to build better documentation, and simply have conversations to build shared understanding. The author quickly elevates conversations to a mythical cure-all status, just to concede that we might have to document our conversations ('vacation photos') and add descriptive pictures to later jog our memories, though he never explains or points to this apparent self-contradiction.

In effect, the author seems to assert that if we just don’t call it documentation (but rather new Agile terms), and keep as simple as is feasible (i.e., pictures of our meeting notes/drawings on a Confluence page), then it will be useful and Agile. But whatever we do, we must not call it documentation.

The author asserts that documentation is fundamentally flawed because two people can read the same document and have different understandings. The author proposes that the answer is, simply (the author tends to trivialize all problems with humor), to have conversations between people to reach a shared understanding. The author doesn’t address the fact that conversations suffer from the same problem as documentation. In reality, people have conversations and come away with different understandings all the time. People forget or modify their once-held shared understandings all the time.

This self-contradiction really becomes apparent when the author starts to acknowledge that we might need some ‘vacation pictures’ of our whiteboard drawings and other notes to jog our memories. Or that we can point to or hold up our ‘story cards' and wave them around emphatically to remind our team members of previous meetings. It seems obvious to me that documentation also serves the same purpose as something to point to, yet the author just glosses over this by saying you might hurt someone if you waved around a document.

It seems to me that the author’s suggested collection of story cards, meeting artifacts, and pictures that are saved later is exactly the simpler, dare we say better, documentation that the author simultaneously advocates is not needed.

Sure, we can all agree that teams often fall into the trap of trying to (mis)use documentation to create shared understanding, and skip having the real conversations. But this seems to me only evidence of a fault in the approach, it doesn’t diminish the potential value of having things written down to circumvent the limitations of human memory and cognition. The author’s rallying behind the value of conversations and shared understanding is totally warranted, but there is no meaningful analysis to the limitations of the suggested approach.

By the time he gets around to lecturing that we shouldn’t have meetings (because they are unproductive) and we should call them workshops instead (because that’s where the real work gets done), I couldn’t listen anymore.

It‘s not bad, but should have been shorter

If you want to understand user story mapping, and stories in general, this is a good book.

But you should stop listening when he goes off course.

some gold, lots of repetition

there are some absolute gold nuggets buried in these chapters. some of the chapters I found somewhat repetitive, however that may be a function of the audiobook not providing sufficient distinctions between concepts and topics. Perhaps these distinctions are more evident when seen on a page.

a must read for anyone who has to build something

I went on to buy the paper copy, but the audio is good enough to repeat.
Patton described how to build AND maintain shared understanding.

VERY Useful!!!

I fully understood the concepts going into this book having been around the Agile process for a while. I even found myself independently coming up with ideas that were taught in this book prior to picking it up. With the full picture and clarity, now, I feel very confident in building better stories and products from them.

Stories, experience, risk and humour in that order

Great reading with the factology, personal experience to relate to and the exact pintch of humour to emphasize. I would appreciate if more content on risk management is added.

A must read for Business Analysts

I was introduced to user story mapping about 5 years ago but never received any formal training. This book really help me to see the whole story of mapping. A must read for BAs.

Essential reading for Product managers

This should be read by any people involved in the product space. It will give senior management a better understanding of how product trans work, developers a better understanding of the PM method, and designers would get better alignment with the stories approach.