Join the DZone community and get the full member experience.
Join For Free
Now I know some people dislike backlogs - queues, wait states, work we want done - and I buy the argument. But the Scrum Sprint (Iteration) and Product Backlog model actually fits for a lot of organizations.
Maybe it's a temporary state before moving to continuous flow, continuous value but it might also be a sensible state for many organizations. The Product Backlog is stuff they would like to do but haven’t gotten around to yet.
While I generally accept and teach the Product/Sprint backlog model (all the stuff we might do sometime in the future / the stuff we are of focused on for the next two weeks) I keep thinking its wrong.
There should be
Three Backlogs
1.
Opportunity backlog: all the ideas which have been suggested ever and have been considered worthwhile for recording. Recording such ideas does not in any way commit anybody to actually undertaking them.
2. Validated backlog: items from the opportunity backlog which have been examined, researched and discussed enough to be considered valid candidates for future development.
3.
Iteration/Sprint backlog: the work that will be attempted in the current iteration.
While the iteration/sprint backlog plays the same role as it ever did - setting the agenda for the next iteration - splitting the product backlog allows for a clear separate of "good ideas" and "validated ideas." Moving from the former to the latter involves checking ideas with stakeholders, measuring them against the over-arching goal, considering the benefits in the market or to the organizations and perhaps conducting experiments to measure benefits.
This three backlog model naturally maps to the
three planning horizons I described a while back, and to the commonly used Epic, Story, Task work breakdown used by teams:
- Opportunity backlog contains big items with little breakdown, Epics. These may be happen sometime in the longer term, over future quarters and years. They may appear on a roadmap or they may be more speculative.
- Validated backlog items should be at the story size - small enough to be deliverable soon but demonstrating real business value. These items may be developed sometime in the next quarter so they appear on the quarterly plan.
- Iteration backlog items are here and now, they are task sized and are in the current iteration.
There is no point in doing more work on any item until it moves to the next backlog, into the next planning horizon. At each stage some items will disappear, upon closer examination they will not be judged worthwhile.
Epics need not be broken down in their entirety before any work is undertaken. Ideally the first stories broken out of any epic would be experiments which could test technology options and, more importantly, market and client reaction.
For example the first stories for an epic entitled "Launch French version" might describe a series of data gathering experiments to assess the size of the market and opportunities. Translation, payment and such can wait, they might never need doing.
As for estimation:
- Items in the Iteration backlog may well have detailed effort estimates arrived at from work breakdown if needed
- Items in the Validated backlog probably have ballpark estimates and, very importantly, value estimates (how much is this item worth?)
- Items in the Opportunity backlog might have effort scores taken from historical averages (why spend time estimating something that might not happen?) and can only move to the Validated backlog when a value estimate has been made and the item has been judged as worth doing relative to everything else
Three backlogs. What do you think? Good idea or silly?
Like This Article? Read More From DZone
Topics:
Published at DZone with permission of Allan Kelly , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}