A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do. A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that delivery value to users and business with each release.
Presentation Notes
The modeling approach used for story mapping evolved out of blending the practice of Constantine & Lockwood’s Task Modeling with the user story writing workshops. Our initial goal is to understand the various users and uses of the whole system. Given that understanding we can begin to prioritize the bits of usage we’ll choose to support in the system. The planning approach used in story mapping was first describe in this January 2005 Better Software Article titled, HOW YOU SLICE IT.
After initial discovery and planning, the user story map serves as an excellent visualization that supports ad hoc day to day conversations about the system, its functionality, its users, and the typical lifecycle of use. The stories contained in a typical story map may be high level – they type used in initial backlog formation and planning. But the story map works just like a physical geographical map allowing you quickly find the “place” in the system’s workflow where the specific story you’re working on is located. Once you’ve found that location in the story map, a wealth of context comes in with it such as the primary user involved, secondary users and stakeholders important to the process, the goals of the user involved, the work they’re engaged in, as well as what they were doing before, and what comes next.
The user story map provides a useful tool for the entire team to understand the big picture – to see the entire breadth of the system and its diverse set of users and uses.
180 minutes