Story Mapping to Reach Shared Understanding

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.

Image for post
Image for post
User Story Mapping by Jeff Patton (O’Reilly, 2014)

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.

Image for post
Image for post
A simple Story Map

This simple format provides a number of benefits:

  • It organizes your Stories logically.

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.

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.

Written by

Writer and technology leader. Living and working in Cincinnati.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store