Backlog Lacks the Backbone

Backlogs have been under criticism for some time now. Lean considers them as inventory and waste. Mary Poppendieck goes to the extent of suggesting that product backlog should be eliminated if it is not satisfying the desired purpose. On similar lines Jeff Patton suggested that flat backlogs fail to convey high level view of the system. He suggested using a story map instead.

According to Jeff, one of the most common problems that Agile teams face is that they quickly lose the big picture. The reason for this is the way stories are arranged completely ignoring the system which is being built. Jeff drew an interesting analogy,

"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."

Jeff suggested using a story map instead of the backlog. The story map looks like this

Here, at top of the map, are big stories or activities that the users do when they interact with the system. The order of the activities is the order in which the user interacts with the system. Below the activities are the user tasks. These are the collection of tasks that the user performs to accomplish the activity. For example, if managing email is an activity then "send message," "read message," "delete message," "mark message as spam" etc are user tasks.

Jeff added that the activities on the map form the backbone of the system and the tasks are the ribs. The idea is not to prioritize the backbone because it is the foundation on which the system hinges. However, the stories should be prioritized. All the planning should be done on the basis of backbone and that is helpful in deciding on the priority of the user tasks which form the ribs.

The benefit of using a story map are that the big picture is now a central theme. Apart from this other benefits that Jeff suggested were,

I can walk the map from beginning to end with a user, stakeholder, or developer and tell a story about the users of the system and what they're doing. I can skim along the top of the map, and just touch on the high points. I can dig down into the map to discuss the details.

Talking through the map with users and others helps me find things I've missed. I often hear "you've missed a couple steps here" from users when doing this.

I can annotate the map with pain points or opportunities. As I talk through the map with a user it's common to hear him say, "this here is really a problem with the system today."

Thus, a story map helps the team to constantly focus on the product that they are building. It helps the teams not to lose focus on the forest for the trees.