BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Backlog Lacks the Backbone

Backlog Lacks the Backbone

Leia em Português

This item in japanese

Bookmarks

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

Story Map

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.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • How to focus on the big picture?

    by Vikas Hazrati,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Are there other ways to keep a constant focus on the big picture? or as Jeff mentioned story maps might be the silver bullet!

  • this is called a use case hierarchy

    by Jeff Anderson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    what you are suggesting is great, but it's pretty much covered by the style of use case development recommended by Alastair Cockburn,

    yes, use cases can be done in an agile way,please see my post@ agileconsulting.blogspot.com/2008/02/can-use-ca...

    Jeff Anderson
    agileconsulting.blogspot.com

  • Re: How to focus on the big picture?

    by Jason Yip,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    At least from a tracking point of view Feature Driven Development parking lot diagrams are useful to keep the big picture in mind. Otherwise, as Jeff Anderson mentioned, Cockburn-style use cases.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT