This past Wednesday evening I attended the Agile meet-up in San Mateo where Chris Sims of Agile Learning Labs presented on story mapping, an alternative to the Scrum backlog. What I found interesting, however, was not so much story mapping itself as Chris’s low tech presentation.
So what is story mapping? In Scrum, user stories are listed in a prioritized list called the backlog. The backlog is the basis for choosing what will be included in each sprint. Jeff Patton writes in How You Slice It that relying on a one-dimensional list results in a deficiency. What if implementing the top priorities does not result in a software product that enables users to complete any particular process? What if some of the lower priority items are essential to make the higher priority items usable? In Jeff Patton’s words, “If you still want to release the software incrementally, how do you choose a first bundle of features that is both high value and immediately useful?”
Jeff Patton advocates organizing the backlog into story maps that visually illustrate relationships between user stories, provide context, and clarify which features need to be released as a set. In practice, this amounts to a hierarchical arrangement of cards posted on a wall. The steps in the parent process are laid out left to right and the user stories, which together form a sub-process, are arranged underneath the parent task.
The idea of story mapping struck me as hardly original. I do not practice Scrum myself so I’m not familiar with the strengths and weaknesses of user stories and backlogs. However, I have always arranged requirements in some sort of hierarchical order so as to make the context clear. And I often use flow charts to help stakeholders visualize how features fit together.
What did strike me as very powerful was the effectiveness of quickly writing down user stories on cards, sticking them on a wall, and arranging them in a meaningful order.
In this case, Chris interviewed a colleague who had once worked in a business card printing shop about the shop’s process from order intake to delivery. Throughout the interview, Chris stuck cards of different colors and sizes on the wall in a hierarchical order. One color was reserved for the user role that performed the action. Another for the main step in the overall process. And the smallest of cards fell in underneath with the user stories written on them. The user stories were simple, single phrase requirements such as “select business card template.” The placement of the cards highlighted gaps and drew out additional questions. The interviewee himself got up and moved cards around and pointed out errors.
My approach has always been to take notes during an interview, ask questions to clarify what the stakeholders have said, and then write up a requirements document after the meeting. As I write up the requirements, more questions come to mind and I follow-up with stakeholders. In some cases, I create flow charts to elicit more questions and make sure I’ve understood everything correctly.
This approach works has worked well for me but there is always room for improvement. If I stuck cards on the wall, the stakeholders could see my notes as I write them, fix any mistakes, discover gaps and issues, and get up to move the cards around for themselves. This low tech approach makes the whole process more collaborative. I can always take a photo of the wall and produce the standard requirements document and flow charts afterwards if that would be useful.
Chris did a great job with the presentation. He is adept at illustrating Agile principles through concrete examples and group activities. If you are interested in learning experiences like this one and you live in the San Francisco bay area, come join the Agile meet-up group.
By the way, you might remember Chris from an earlier post. He introduced me to an Indian restaurant in Foster City. I have since checked it out and the food is fantastic.
Jim Downey 
Leave a Reply