Less is More: Prune your backlog
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
The longer your backlog the longer it will take to deliver anything on it. Being first to market is important. The longer you make your customer wait, the higher the chance they will go to a competitor or your competitor will deliver the same idea before you.
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
The more items you have on your backlog the less likely you are focusing on what needs to be done now and investing time in longer-term items which have inherent uncertainty. It also makes it harder for your team and anyone else who may be interested in the work you have on your radar to decipher what you find important and what isn’t.
Your backlog represents cost that you may never recoup
The more items you have on your backlog the more WIP or inventory you have i.e. work that has been started but not finished. We commonly think that work is only in progress once development has started, but costs are already tied up in backlog items considering someone somewhere has spent time (and therefore money) researching and/or creating it. However, these do not yet have any return on investment and may never if it devalues over time, or isn’t implemented on time.
Markets and organizations are not static
Items can devalue over time leaving you with items whose only purpose has become to make backlog maintenance harder (and cost us more time). For example:
- 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?
When you should start considering pruning your backlog is up to the individual and their own context, in my opinion, and is not necessarily based on a set upper limit (although having hundreds of items is probably not helping). However, there are a few clues that your backlog might be getting a bit out of control:
- 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
It can be scary to think about pruning your backlog, and mustering the courage to say no sometimes (especially to yourself), but what should worry us even more, is the potential waste that you are ultimately generating from not doing so.