Monday, July 01, 2013

Three backlogs?

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 its 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?


  1. I like it. It saves the Product backlog from growing to an unmaintainable mess. Or if that only contains validated features, it avoids neglecting ideas that one haven't had a chance to validate yet. I find it's important for project stakeholders that their ideas are recorded somewhere even if one hasn't had the time to spend on them yet, it avoids frustration on their part.

    Given that the Opportunity backlog hasn't been validated, does this mean that it's unordered, unlike the other two backlogs?

  2. I presume all this would roll up into ONE Product backlog - with different levels of granularity. I agree it is good to have an Opportunity backlog which is an idea at this point of time - which could be "blown up" into an Iteration backlog at a later date.

  3. Jan - I completely agree about making stakeholders feel their needs are recorded. Whatever we think about their ideas we owe it to them to record them (if not why talk to them?). We might well be right in our immediate judgement but we might be wrong.

    Ordering, I hadn't thought about that.
    Obviously the Iteration backlog is ordered.
    I'm imaging items in the Validated Backlog should have some value indication, if these are all numerical (say dollars) then ordering is easy. I'm also imaging the Validated Backlog is closely related to the Quarter Plan which also implies and Ordering.

    The Opportunity Backlog... I suppose it is ordered to the degree that you know what should be evaluated next but to going much further might lead to an excess of planning.

    And that also opens the door to a "Reject Backlog" or perhaps an "Invalidated Backlog" which some might spell b.i.n. but we might want to record it somewhere with reasons for not progressing

  4. I forgot to credit Jeff Patton with the term "Opportunity Backlog". If I recall correctly I picked it up from one of his blog entries:

  5. Several people have responded to this blog on Twitter.

    Importantly two people have (so far) said they actually run a system much like that described.

  6. Dom Davis has written a blog about his experienced using three backlogs

    This is well worth reading and adds a real world example to my theory and some good ideas on implementation.

  7. I'm indeted to Hope Thomas who also responded on Twitter to say she does something similar. Hope has blogged a description of her process:

    Now all I need is a third example of someone doing this and I've met the "Rule of 3" which would justify writing a pattern.

  8. Very much agree. This same idea is around in our development team for the last few months. And we intend to try it out for the next release iteration, that will start this autumn. (I wish I could say we already tried)

    There is a small comment though.

    The second backlog that you, Allan, see as a Validation Backlog, I rather prefer to call a Release Backlog. For us it will contain the items that are committed to the scope of the release or appear to be clear candidates for it. Something that development team will most likely work on soon, but that is not scheduled for the current sprint.

    We also hope that having this second backlog shared/visible to our stakeholders will help to set a clearer expectations on which of their wishes and ideas will, might or will NOT be included into the next release.


Note: only a member of this blog may post a comment.