Story Mapping the Wrong Way


What Did We Get out of It?
By the end of the meeting, I knew I had made several mistakes around the story mapping. I apologized to the team, threw my hands up in a “failure bow,” and said, “How fascinating!” I asked them to applaud my failure. I hoped we would still learn something.

When the meeting concluded, I looked back at my notes on story mapping and found what I’d missed. I went back to the rolling whiteboard and added sticky notes for the missing “user activities” row. (We had implied user activities, but we hadn’t specified them on the whiteboard.) I color-coded some of the details under each user task to reflect which were technical implementations, which were outstanding questions, and which were known tasks. Now, it looked more like a story map (see figure 1).

Figure 1: Story map with color-coded sticky notes

I talked with my teammates to get their feedback on our somewhat misguided “story mapping” attempt. Since they didn’t know how story mapping was supposed to work either, they were OK with it. They felt that we had flushed out some details about stories in the theme that otherwise may not have come out until we started coding.

One programmer observed that he thought the story mapping was valuable because the stakeholder (I’ll call him “Z”) was at the meeting. Often, we only have the product owner to represent the stakeholders. Z turned out to be more receptive to simpler solutions than our product owner, and since he was the actual stakeholder, he got to make decisions. We got more information just from having Z participate in the meeting.

Next Time
We started working on the user stories for this theme in the very next sprint. We felt we were starting with a better shared understanding than we sometimes do for a new theme. We had sliced the theme into appropriately-sized user stories and understood the dependencies between them. However, confusion about part of the model for the underlying relationships cropped up that caused hours of wasted time and discussion. This is just what we were trying to avoid with story mapping, but it still occurred. That was frustrating.

In spite of still having some “requirements churn,” my teammates feel that story mapping is worth trying again. They think it has potential as a brainstorming technique. Next time, we’ll divide into two smaller groups, each will produce a map, and then we’ll consolidate. We’ll know to start with user activities and then drill down into user tasks and details. We’ll try mapping on the conference table, so I’m not the only one writing down the user activities, tasks, and details.

Even failures help us learn. I’m glad that I saw my mistakes and acknowledged them instead of getting discouraged. We improve by trying experiments, and the team is willing to continue this one. I’ll keep you posted!

About the author

Lisa Crispin's picture Lisa Crispin

Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002) and a contributor to Beautiful Testing (O’Reilly, 2009) and Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011). She has worked as a tester on agile teamssince 2000, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine in 2009. For more about Lisa’s work, visit

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!