My team has been organizing our work with User Stories for almost three years. They have been invaluable for helping us break development work down into discrete pieces and deliver value to our users. Recently, though, we’ve been struggling with a problem common to teams that use Stories: how do we ensure that the individual Stories add up to a coherent product? To help me solve that problem, I turned to Jeff Patton’s book User Story Mapping.
The Concept of Story Mapping
Story mapping is a method for understanding both what your product roadmap needs to be and how you should build it. A story map starts with a backbone that describes each step of the process followed by your users. Under each step, you capture development Stories necessary for that step.
For example, let’s imagine a simple account creation process with three steps: Register, Login, and View Account. (In my team’s system, these map to Features.) Under each step are its related Stories. This Story Map can be created on a white board, with Post-Its or index cards.
This simple format provides a number of benefits:
- It organizes your Stories logically.
- It provides a way to rank Stories according to value, which can then be used to generate sprints and versions. For example, under Register, I have the Story “Password security,” to capture the need to implement password requirements. Perhaps this Story isn’t necessary to complete in the first sprint, because the app is running only on local servers, with only demo users. But this Story will absolutely be required to complete before first version.
- It exposes gaps in your process. Under View Account is the Story “Change password.” What kind of validation will we need for changing a password? Should we also allow users to change their username?
Mostly importantly, though, the Story Map creates a vehicle for shared understanding.
Aiming for Shared Understanding
The real goal of using stories is shared understanding. —Jeff Patton
Before picking up Patton’s book, I clearly saw the value of Stories for organizing development work, but I overlooked their importance in building consensus and deepening our understanding of the product. I engaged our stakeholders at the level above Stories, to make sure they agreed with the Features/Epics. When a developer didn’t understand a Story that I’d written, or our tester passed a Story for meeting all acceptance criteria even though it didn’t really do what was expected, I thought the problem was with my writing. Next time, I would try to write the Story even more precisely, and then everything would be OK.
But that’s how it works. Patton points out that the point of a Story is that it’s a story, something that one person tells to another. No matter how detailed or evocative the written description of the software, it is incredibly easy to misunderstand something that only exists in writing. Our goal in writing the Story isn’t to have a Story, but to make sure that everyone involved in the project has a shared understanding of what needs to be developed. Our Stories, then, will serve as reminders of the conversations that we’ve had about the product as we’ve worked together to come to shared understanding.
I still write the Story, but then I talk. And I talk some more. I talk with developers, with testers, with customer support, with marketing, with the CEO — talk with everyone until we reach a shared understanding. This is time-consuming, yes, but it’s much less time-consuming than writing the wrong software for a few months. By the time we finish talking, the true Stories are in our heads. All of our heads — not just mine, not just the CEO’s, but everyone’s.
A Real World Success
The next major version of our software focuses on improving a complicated ordering process. Our company manufacture a components-based closet system, which requires detailed designs and precise parts lists. The designs usually pass through several people’s hands — figuratively and literally — before our customer is ready to order the necessary parts from us. Frequently, there’s a problem that interrupts the order. Our customer doesn’t have the correct final design, their order has to be manually entered into our system, or there’s crucial information that has to be hunted down before the order can be placed.
Our development team came up with an idea that we thought would solve everyone’s problems. However, we didn’t know if it would solve our customers’ problems, and we needed to ensure that the whole process would work smoothly. We also needed to understand what, exactly, we would need to create for this solution.
Using Lucidchart to create a flow chart of the business process, and simple Post-Its and index cards to represent Stories, we quickly iterated through several levels of conversation:
- Our development team created a basic Story Map to refine the process and identify questions we needed to answer.
- Next, we met with representatives from our customer support and sales teams. We walked them through the Story Map that we had created. This part was critical, because we needed to bring them along the same journey of discovery that we had experienced, so that we could build shared understanding of the solution. They helped us refine the Story Map with important knowledge about our customers, identified gaps in the Maps, and answered the questions that we had.
- Then I did the same thing with our CEO and Director of Marketing. Not only did they endorse the solution, but our CEO also pointed out a key improvement that cut out a couple of steps.
At this point, it was easy to review this change with our developers, customer support, and sales representatives. Because they understood the Story Map already, they could affirm the CEO’s change as a better alternative.
How long did this process take? Much less time than I expected. My initial concern with Patton’s method was that it seemed to require large amounts of dedicated time. His examples often referred to one-day or two-day planning sessions with large groups of people. As a small company, we can’t afford to organize planning sessions like that, because then there will be no one to answer phones or keep the servers running. We were able to build a solid Story Map over several smaller meetings, 1 or 2 hours at a time. In total, it took about 2 weeks to move from initial concept to a complete development plan.
Most importantly, we now have a well-defined solution, endorsed by both senior leadership and those closest to our users, thoroughly understood by the development team. I’m excited to start work on the project next quarter and continue using Story Maps from here on.