User Story Mapping—Goal-Driven Backlog Development
Steve Rogalsky posted a good explanation of how to do user story mapping—a technique for assuring that you are delivering value, not just a list of features in your product. When a product manager is planning what the product releases will include, the goal is to deliver value for the customers and users.
For both agile and waterfall processes, one of the bigger risks is that a product release will include a collection of shiny objects or features. Every release of a product should make it better than the previous release. User story mapping is a technique for assuring that each release or iteration makes the product tangibly better.
An outside-in approach to developing great products starts with market-sensing—understanding the problems that are important to your market. You don’t solve problems with features. In fact, your product doesn’t solve problems. Your users solve problems—and your goal is to create a product that helps them solve or avoid problems.
User story mapping forces you to explicitly understand the processes that users follow or will follow to solve problems and the value-chain or workflow by which these users achieve their goals. Jeff Patton has shared a great presentation that explains this in much more detail.
Big-bang software and IT-system releases are often specified with massive requirements documents that include long lists of stuff to do. A couple of decades ago, people realized that long lists—with often hundreds of items—are particularly difficult to consume and manage in documents, so they started moving them into spreadsheets. These long lists became easy to manage as long as you were willing to forget about delivering value and focus instead on delivering all of the items on the list.
This is one of the manifestations of bad-software-development practices that helped spur the move to agile development processes and incremental delivery—breaking that massive list into a collection of smaller lists. Working in sprints improves the execution aspects of software delivery, but if that’s all you do, you’re still just executing against a list of stuff to do, albeit more efficiently.
Jeff Patton refers to this as a flat backlog—a list of stories that fails to provide any connection to the value that is to be delivered to users who are trying to solve problems. With user story mapping, you organize the user stories or tasks that users perform into groups that identify which stories are collectively required to deliver value.
This is a powerful technique for assessing the completeness of your requirements. It also gives you a tool for assuring that each release or iteration adds value by enabling a user to solve, or more effectively solve, a problem—avoiding a delivery that only solves half of a problem.
The user story map gives you a tool for organizing what is included in each release—solutions to problems. This also drives you to think about incremental releases becoming incrementally more useful at solving problems, instead of becoming incrementally less incomplete at solving problems.
