« Web Designers vs. Web Developers | Main | Button as Progress Bar »

Story Mapping

All this time, I thought it was just me. I lost count of how many stakeholder meetings I've conducted, whether to a client or to an internal team, during which we would all walk through a massive spreadsheet of user stories and features. There would always be this unexpressed worry that nobody was brave enough to express that goes something like this "How do we know we've captured everything?" When presented with an exhaustive list of things to build, it appears as if it's all been accounted for, but there are a few perceptual and cognitive factors working against this process.

First, a cognitive issue, spreadsheets filled with row after row of great ideas end up overwhelming the reader with too much data. Even if features & stories are categorized well, the reader most often can not see all categories and all items at a glance, and there is a known law called Miller's Law, or Seven Plus or minus two at work here. People can think of (keep in RAM) as few as five objects at once and as many as nine things. So it's no wonder that after running down the list of features, eyes start darting around the room checking to see if others are feeling the same way. Not being able to see the big picture in situations like this makes people nervous. Period.

In the middle of a recent redesign, our team experienced something like this. After a month of incredible user research, the creation of personas, scenarios and a features list, there was this nagging feeling that something was missing. It became difficult to talk about the redesign with anyone outside of the core UX team. So I took to the interwebs for a blast of research.

I stumbled upon the work of Jeff Patton on the Agile Product Design site and struck gold. This quote summarizes his thinking.

"We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details - the pieces of functionality we'd like to build. In my head a see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations."

"After all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag - then cut down the tree."

"That's what a flat backlog is to me. A bag of context-free mulch."

I need that context in order for me to really tell a story about the system.

: Jeff Patton

When I read that quote, I felt as if someone had read my mind. So I immediately claimed a wall in our office, in the kitchen area with the highest traffic, and the largest open wall space. I wanted this to happen in "public" so that during the process my teammates across all disciplines would be drawn into conversation and help to uncover any gaps.


[ to be continued ]

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>