User Story Mapping

"This book provides an overview of a process (story mapping) that can help to increase understanding of a feature before building it. Doing so helps to prevent scope creep and gets multiple members of a team on the same page about what will be built.<br/><br/>Story mapping:<br/>• is a way of talking about who does something, what it is, and why they do it. It also helps us prioritize and agree on the most important paths users need to take, which helps us make decisions down the line<br/>• is used to build shared understanding. Stories are a lightweight form of documentation that is primarily spoken, not written. <br/>• is a collaborative process used to flesh out what needs to be created. Unlike traditional requirements where one person explains and another tries to understand, story mapping aims to get people talking about the best way to solve a problem.<br/>• establishes order and hierarchy. It helps to group things in sequence and by priority. It reveals gaps in understanding and shows how things fit together.<br/>• shows what parts of our understanding are unclear so that we can identify key unknowns to study going forward.<br/><br/>Although the process is clearly described and immediately applicable, I found Patton's context of when to use story mapping to be a bit disturbing. He writes about using story mapping to fully explore a feature based on what we think people need, and then creating a quick prototype in order to test whether that's what people actually need. He includes diagrams showing this cycle of guessing what people need, then checking whether that's what they actually want, then guessing what they need again.<br/><br/>To me that's problematic because he only tacks on a chapter about formative research toward the end of the book, and when he does, he doesn't describe its integration with the rest of the process. Without that formative research before the story mapping, we could very well become invested in the details of a feature that serves no real user need. After starting down the wrong trajectory, we could be iteratively testing and trying to improve something that doesn't serve any real need.<br/><br/><br/>"