Fix It Or Forget It

As an agile practitioner, how much time do you spend looking after your backlog? How much in meetings with names that include one of the words "grooming", "triage", "prioritisation" or "pruning" in the invite? What about debating whether you should have separate columns on your Kanban board for bugs? For technical debt? For ideas?

What if you didn't spend time doing any of those things?

What if we let go of our compulsion to track every idea we have and each issue we encounter? I know, we write these things down "just in case" or "for when we have more time". It's comforting to know that the information we have diligently acquired is safely stored away, ready to be used at a later date. To throw that valuable information away would be irresponsible. Why would we do that?

Fundamentally, if we're adding items to our backlog faster than we can process them, the size of our backlog is tending towards infinity. If you're on a team which is not adding items to its backlog faster than it can process them, congratulations. You can stop reading here. For the rest of us, we're heading towards the point where maintaining that backlog is soon going to be an unsustainable effort.

The Cost of Managing the Backlog

Those of you who are students of lean software development practices will be familiar with the idea of "inventory", in the form of unfinished backlog items, as waste. I would argue that even unstarted backlog items should be considered inventory, as they still have storage costs. These storage costs can take the form of additional effort expended to prioritise the items, extra time spent ensuring that correct metadata is applied to the items, or less efficient searching of the backlog. We often underestimate the storage cost, because for a single backlog item, it doesn't seem very great. The cost of storing and managing a single item is far exceeded by the cost of re-acquiring the information required to begin work on that item.

However, once we are dealing with many backlog items, the storage costs begin to mount up. That would be fine if we were going to process every single item, but because our backlog is tending towards infinity, it's inevitable that we are in fact going to end up processing a smaller and smaller percentage of items as time progresses. At some point, the cost of managing the backlog is going to be greater than the cost of re-acquiring the information to work on every item the team might realistically deliver. This is especially true given that information is subject to the law of entropy, so the effort required to battle the degradation of the backlog will also increase over time. Eventually, the only way out is to declare backlog bankruptcy, and start from scratch.

Unfortunately, declaring backlog bankruptcy is an emotionally difficult action. Most teams put it off for far too long. After all, nobody wants to declare bankruptcy, do they? Society generally considers that the bankrupt have been irresponsible or profligate in some way, or at best unlucky. Teams are also often subject to the sunk cost fallacy, unable to bear throwing away that precious information they have invested so much effort in maintaining. It's better to avoid getting close to bankruptcy at all, if possible.

What Can We Do instead?

Unfortunately, if you're already spending far too much time on your backlog, bankruptcy is your only way out. The key question is "how can we avoid repeating the cycle again?".

As far as I can see, there's only one way to break the cycle. I call it "fix it or forget it" (at least one other word beginning with "f" may be used in place of "forget"). This means that every time you are deciding whether or not to add an item to your backlog, whether it's a bug fix, a feature idea, or a refactoring, you ask yourself the following question: "are we going to work on this within the next month?". If the answer is no, you don't add the item. You should ask yourself the same question when you are prioritising each backlog item, and if the answer is "no", you should delete it. You should review every item at least once a month. Remember to adjust your answer to the question depending on your team's velocity, otherwise you could still find your backlog growing at an alarming rate.

To be very clear, this is not carte blanche to neglect your product roadmap. You should still have a lightweight artefact describing your intended direction over at least the next few months, and perhaps further depending on the maturity of your service and the rapidity of change in your operating environment. Be careful, however, not to shift the problem from one place to another. It's tempting to start recording every new feature idea you have in a roadmap document somewhere once you have decided to stop using your backlog for the purpose.

Likewise, it's not an excuse to avoid fixing bugs. On healthy teams, bug fixes will be considered a top priority. Given that bugs are a subset of backlog items, they are subject to the same mathematical rules. The number of known bugs in your system can only have two stable states - no known bugs, and infinite known bugs. The only way to stay at or close to no known bugs is to fix them as soon as they are reported. Teams that have not taken that approach, however, may find that bugs are manifesting faster than they can process them, in which case recording those considered too low priority to fix is not going to help matters. Reducing the cost of managing the backlog in favour of investing in high-priority bug fixes is probably a sensible choice for such a team.

What's the Worst That Could Happen?

If you're still not sure about declaring backlog bankruptcy and going in to "fix it or forget it" mode, ask yourself this: "what would happen if I deleted the entire backlog?". Chances are, nobody would even notice. The sun will still come up tomorrow. The team will still carry on working more or less the same as they usually do. A few items might need re-defining, but there's a high probability that those items were only added to the backlog fairly recently and the team will remember enough about them to reconstruct them with little effort.

There are a few things that definitely will happen though. You'll never have to roll up your sleeves and decide it's time to spend a half-day "pruning" the backlog again. No team member will ever look at the enormous backlog and think "we're never going to be able to do all of this". You'll never receive a bug report and spend ten minutes searching for that related Trello card you think you might have created six months ago. "Fix it or forget it" isn't going to solve all of your problems. You still need to make good product decisions and sound technical choices. But it will make it easier to focus on the important stuff.