That darn backlog there is so much stuff in it!

  I used to be a believer that when a good idea came around you should throw it on the backlog.  Those ideas (or bugs) live on the backlog indefinitely waiting for their chance to "dance".  As I re-evaluate my thinking from a Lean perspective I am reconsidering that approach.  In Lean maintaining large amounts of inventory (queued inventory) is frowned up.  Without going into all the gory detail of Lean (if you are an Agilist, want to be an Agilist, or develop software go read about Lean and think about it in terms of your software development process – it will be good for you) large amounts of inventory lead to "inventory rot".  In the software world this amounts to requirements that were scoped two years ago by a Business Analyst that is no longer around or a bug reported by a tester two releases ago.  The information relevance in those backlog items has dropped considerably during the time that they were idle.  As time goes on and it becomes obvious that prioritizing them won’t happen – close them.  Dump them.  If they are important they will show up again.

  In addition to trimming the backlog appropriately it may make sense to have tiered backlogs.  There will be a Sprint backlog (or Iteration Plan) that represents the work in flight.  It is useful to have an "on deck" backlog that represents the work coming up in the next 6 months or so.  The "long range" backlog represents those ideas and concepts that are more "out there" and likely are fairly vague, large, and inestimable.  Each backlog requires different types of care and feeding and involves different sets of people in the care and feeding process.  The Sprint backlog is the focus of the team, talked about in Standup as people report progress, and the tactical focus.  The On-Deck Backlog should be actively worked by the Business Analyst, Customers, Technical Lead/Architect, and Project Manager.  Perhaps this is a weekly, bi-weekly, or monthly meeting.  The Long Range backlog is likely discussed perhaps monthly or quarterly as needed to identify items ready to move on-deck and be fleshed out, identify new directions that need to be captured, and obsolete ideas that are no longer applicable (don’t forget this one!).

  With bugs I subscribe to the Broken Window theory.  The more you have the less likely you are to care.  You have to be careful with that of course – take it too far and you end up with a product with no bugs, but no features either because you have spent all your time fixing bugs that weren’t important.  Once a bug has been identified as costing more to fix than it is worth you start to have a case for closing it and dropping it off the bug backlog.

  The goal is to make sure your focus is where it needs to be.  Your Sprint Backlog efforts should be  focused on execution.  Moving those items through the development process as effectively as you can.  On-Deck Backlog efforts should be focused around locking down the requirements for the items so that they are ready to be executed on (a blog on how critical it is to do requirements definition is in the works).  The Long Range backlog efforts should be focused around making sure that you have outlined the key strategic elements for the future and analyzing them in the context of the market you are serving to see what value propositions make the most sense to pursue.


Note: I use this blog to post both Personal and Technical articles.  For a technical only feed use the following URL (  For a family only feed use the following URL (

This entry was posted in Technology. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s