Detailing Backlog Appropriately
1 July 2013
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.
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.
Current rating: 5 (3 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.