Detailing Backlog Appropriately

1 July 2013

Rajat Bhalla
Appster Pty Ltd.

 
On one of the projects I am currently managing, I noticed that the product backlog was actually growing rather than shrinking as we progressed through sprints. At one point, there were close to 150 stories in the backlog, all detailed and ready for planning. Some were even accompanied by ready UI designs. The reason for the increasing backlog size was that everything under the sun was being thrown into it for future development. While this might sound fine -- you would want to write down somewhere the features you might need in the future, and what better place to write them down than in the backlog? -- there was definitely something going wrong.
 
I realized that every time we planned a new sprint, instead of picking previously written stories from the backlog, we were writing new stories, as the client had come up with a new feature that had priority over rest of the backlog. This is completely understandable and even recommended. After all, you would like to use the feedback you're receiving from the market to add new features. If the window of opportunity for a new feature is now, there's no point in putting it on a backlog for later. It requires attention now.
 
But what about all the other stories in the backlog, and the effort invested in detailing them and designing the UI for them? Soon they would become obsolete, never seeing the light of the day. If their turn ever came, they would require changes in both functionality and the UI expected, as the current functionality would have undergone changes by then. In terms of Lean thinking, this was clearly muda ("waste" in Japanese). I could have done better things with the time I'd invested in detailing those stories and helping create their UI design.
 
The other day, I was watching a show on television (I think it was Comedy Central), and I noticed the way they presented their schedule:
 
· Now (the show currently being telecast)
· Later (the show after the current one)
· Never (the show after the "later" one)
 
This was a fun way to provide a relative schedule, especially the "never" part. Considering that I am always in a "meta" state of mind, looking at things outside their current context and trying to correlate aspects from different contexts, the schedule format hit me as a solution to my backlog problem.
 
While the stories in the current and immediate next sprint (the "Now" part of the backlog) would be detailed enough, the stories in the next two to three sprints (the "Later" part of the backlog) would be relatively coarse grained. Stories even further down in the backlog (the "Never" part of the backlog) would have no detail whatsoever. They could be as simple as a single line, a five-word statement (similar to epics in Scrum parlance). This would help the backlog stay current and sharp, help me focus my time on more important tasks, and reduce waste. Of course we would continue to add to the backlog any item we "might" need in the future, but it would not be as detailed as before. It would simply be a reminder, like an item on a to-do list.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (3 ratings)

Comments

Anu Smalley, CSP,CSM,CSPO, 7/1/2013 2:42:22 PM
Rajat - One of the things I found useful as a Product Owner is to "review" the product backlog with the business at regular interval as we prioritize items on the backlog and do some housecleaning. I found at one point that our backlog was over 200 items with some stories in there from over 2 years ago - falling victim to the same thing you described. Purging stories that are in the backlog that were once created with all good intentions but would never be worked upon given the current situation and circumstances has worked well for me.
Kapil Dhawan, CSM,CSPO, 7/1/2013 10:08:37 PM
Rajat - That's exactly the way I have worked. We went strictly with priority, clarity available and detailed only those which are going to be handled soon and left remaining for future detailing.
Ashish Mahajan, CSM,CSPO, 7/3/2013 1:59:35 AM
good one!
Sidiropoulos kyriakos, CSM, 7/3/2013 6:35:13 AM
It sounds like a healthy backlog to me, except he detailing and the UI design. This should be done within the sprint. The rest should only be stories.
Sweta Paul, CSM, 7/10/2013 5:11:59 AM
We have 'Backlog grooming' sessions to reprioritise the backlog based on business priority, and add new items in. And as suggested, only those prioritised for the next release (each release would consist of 3 three week sprints), would be fleshed out with details.

You must Login or Signup to comment.