Book Review: User Story Mapping

Book Review: User Story Mapping

One of the most talented developers I’ve ever worked with recommended this book to me.  A guy who, at least when a big financial is his client, finds himself arguing against documentation more often than for it recommending a book about requirement documentation? Figured it must be worth the read.  It very much was, I got a lot out of it and have already used Story Mapping on two of my projects.  My only gripe was that the book could have been a lot shorter, the concept of Story Mapping is really a simple one.  I feel like Patton felt he had to include sections on good story writing just to fill up the book, but the real value is in the technique for Story Mapping.

I’m not going to try to reproduce the manual for story mapping here, but I will say it has helped me with a few key things.  If you’re struggling with them on any of your projects, you should definitely read this book:

  1. Defining a TRUE Minimum Viable Product (MVP).  The way story mapping works is focused on what your user needs to do.  The features are aligned to that.  It really helps with the, “Well, if they didn’t have feature XYZ, couldn’t they still do ABC?”  Even if ABC is an ugly work around, it may be a way to get you to providing value to your customers earlier.
  2. It’s not just the MVP, story mapping is an excellent tool for release planning.  This has really helped with a project I’m working on around enabling enterprise technology for automated provisioning.  We did a full story map and are now thinking about things in terms of releases that are similar (but not the same if you happen to know for whom I work):  1.  Just make sure the hosting team can use it to avoid some of their annoying manual steps.  2.  Enable rapid provisioning of test environments so that they can be shut down when not being used and quickly stood up when necessary.  3.  Start letting developers test on rapidly provisioned environments with real hardware instead of on their desktops.  It is helpful for prioritization to think of things like “automate DB deployments” not as an independent features that we race through but as necessary building blocks of one of our well-thought out, value-based releases.
  3. Figuring out the role of the “product owner” in an organization where you don’t have an actual user of the software that can play it.  You’ll have to dig for this bit of wisdom from the user story tutorial part.  While most of that section is motherhood and apple pie, I think his approach is a nugget of gold.  Actually led me to ask the team on my current project to make me Product Owner.