Allan Kelly

About Allan Kelly

Allan Kelly has held just about every job in IT, these days he provides training and consulting in development management, processes & products, especially around Agile. He specializes in working with software product companies, aligning company strategy with products and processes. More about Allan at http://www.softwarestrategy.co.uk/allankelly

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?
 

Reference: Three backlogs? from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


× three = 3



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close