Story Mapping the Wrong Way


When Lisa Crispin’s team got an opportunity to put the story mapping ideas she picked up from Jeff Patton into practice, they excitedly rushed into it and missed a few steps. Find out what happened, what didn't happen, and what they learned from it all.

During the past few years, I’ve participated in a couple of workshops and talks by Jeff Patton where I learned about story mapping. This is a hands-on way to model a theme or project and slice it into user stories. Jeff first wrote about it in a January 2005 Better Software article, “How You Slice It.”

What I learned from Jeff is to start by gathering your development team and business stakeholders. Create personas to represent your various types and roles of users, then think about how each persona would use your system or feature. What would they do first? What would they do next? Make a timeline of user activities using index cards on a wall, a table, or a floor. Then, go back and look at each user activity in detail and create user tasks and details about those tasks, which will eventually become user stories. Write those on cards, too, and stack them vertically under the corresponding user activity.

Once the story map is in place, you can slice them into user stories and plan which ones go into each iteration and release. You should walk the story map with stakeholders and see if you can think of any other details or issues. The story map helps you think about the value the system delivers.

Eager to Try It
Like most teams I know, our team struggles with getting the right level of detail on requirements for each user story before we start testing and coding. We don’t want big design up front, but we don’t want to waste a bunch of time going back and forth to the product owner and other business experts to nail down specifications during development. Brainstorming techniques such as mind mapping have helped us, but we still feel we lose too much time with requirements churn.

I’ve been agitating for some time to try story mapping and see if it might help us flesh out details about a theme and its user stories in advance of coding. I was pleased one recent afternoon when our ScrumMaster told me, “We want to story map the ‘We Help You Choose’ theme tomorrow.”

I was thrilled to finally get my wish, but I was also swamped. I was leaving for Agile Testing Days in Potsdam in a couple days, and we were in the middle of a difficult and busy sprint. I didn’t have time to go back and study up on exactly how to do story mapping. I thought I could wing it. (Cue shark attack music.)

One thing I understood about story mapping is that all stakeholders need to participate. We’re often missing important stakeholders in our brainstorming and estimating meetings, so I insisted that all stakeholders for this theme must be present for our story mapping session. In this case, that was only one person, but many themes we do involve multiple stakeholders.

User Comments

1 comment
Mark Hart's picture

The phrases "user stories" and "requirements" were linked in the article. 

"...our team struggles with getting the right level of detail on requirements for each user story.”


An assumption was a concern:

"our stakeholders knew almost nothing about these sales reps" ... we created the persona of "Sammy Sales Rep"... we assumed that "he was interested only in making the sale."

Did you assess errors due to the lack of first-hand experience with customers? Did you have concerns about generalizing a sales persona with little more than an understanding based on stereotypes? Did you have confidence that the persona you developed applied to at least half of the sales force?


The following consensus was a concern: ”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"

A "shared understanding" about stories and requirements is harmful if it is incorrect or insufficient. It seems that the assembled brainstorming group was limited to opinions that should have been characterized their deliverables as hypotheses that needed to be validated before coding.


I prefer a strategy of developing a better understanding over a shared understanding. With a better understanding, which improves through cycles of synthesis, testing, and observing interactions between the proposed solutions and stakeholders (such as customers, sales representatives,…), the development team is positioned to appreciate the requirements that emerge and adapt to provide better solutions more efficiently.

February 26, 2015 - 3:29pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.