Less is More: Prune your backlog

Photographic Collection from Australia [CC BY 2.0 (https://creativecommons.org/licenses/by/2.0)]

I’m going to talk about something briefly that isn’t revolutionary. It’s not new. It’s not mind-blowing. But it is, I feel, one of those things that when said “out loud” makes you nod your head in guilty silence.

More often then not, the product backlogs that I see are enormous and rather unruly like an eighty-year-old apple tree on the side of some winding backroad. Not surprisingly, the longer the team has been around for, the longer the backlog and the more ‘dead weight’ it has accrued.

Unintentionally, it frequently becomes a ‘dumping ground’ of sorts for anything and everything related to the team’s work that may or may not be needed now or in the long-term. Like pruning a tree to help keep it healthy (and thus increase flowering and fruit), there are several reasons why you should be brutal in thinning out your backlog and thinking twice about the items that are put there.

Cost of Delay

Likewise, technical work on your backlog such as refactoring, if ignored for long enough, increase the risk of system failure or put you in a place where a complete re-write might even be more appealing.

Why is this the case? Because the bigger your backlog, the more ‘noise’ there is and the more time is needed to sort through it and maintain it.

Loss of Focus

Your backlog represents cost that you may never recoup

Markets and organizations are not static

  • Context and knowledge can be lost over time as the organization changes (no one remembers why the ticket is in the backlog, or how to find a bug reported a year ago) leading to time spent on rework — or throwing it out (no ROI)
  • Market demand can shift so that you can miss the window of opportunity during which a PBI will be able to have ROI

When to prune?

  • You feel you don’t know what’s on your backlog anymore
  • You notice that a large number of items are older than 3–6 months (on the conservative side)
  • You start feeling you need to create another list(s) of ‘unprioritized’ items so that you can focus*
  • You come across items that you forgot about

*Sometimes an ‘icebox’ is used where immature ideas live, waiting for their time to come. This often comes in the form of another column or list called ‘ideas/ icebox’, or sometimes its a completely separate tool. This is not inherently a bad technique, but we still need to be careful that we aren’t transferring the problem from one list to another.

Instead, we need to frequently consider the points above, and ensure that we aren’t starting new work that we do not yet have the capacity to follow through on, and that will subsequently detract from progress made on other items we have already deemed important and/ or urgent. If the input rate is greater than the output rate, there is only one result.

Summary

An Agile Coach who writes from time to time about his thoughts and experiences.