“Nuke the backlog” originally a quick comment in a podcast about OKRs it summed up what I had come to believe. “Honey, I shrunk the backlog” presentation expands on that idea and outlines why I think teams should replace backlogs with just-in-time story generators – powered by OKRs or some other goal setting technique.
So I shouldn’t have been surprised when this question arrived in my mailbox:
“Throw away the backlog, is that for old bug tickets too? How does that work?”
The short answer is “Yes, throw away the bug list too.”
What do you mean, “Bug” ?
Basically the things we call bugs can be divide in two. Some are actual defects – things the system should never have done and quite possibly are detrimental to the running of the system. Everything else might be considered an enhancement. Logical right? Only where do you draw the line?
If I hit return 50 times and the system crashes the machine that is clearly a bug, the machine should not crash. But then again, how likely is someone to press return 50 times? Let me suggest not very often. And if they do, what are the chances of them doing it again? After all, there is a very easy work around. So while this might be a bug it might also be considered an enhancement request.
Ultimately, where you draw the line between bug and enhancement is subjective. This becomes really clear when you can count known bugs in single digits, 5 instead of 500. Until then calling a “change request” a bug is little more than an attempt to exert leverage and prioritise work. Calling it a bug might also have some other beneficial effect: apportioning blame might further another argument and moving a change from CapEx to OpEx column might help balance the books.
Consider all bugs from a priority point of view instead. While many different scales are used there are basically 3 categories: #1 must be done and done soon, #2 really should be done but not right now, and #3 should done but can be put off indefinitely.
Categories #1 and #3 are easy: the first are just done, the third are ignored forever but we kid ourselves that one day we’ll do them (right after we fix climate change, famine, war and pestilence.) Still, it is relatively easy to close all #3 reports over 12 months old. And next month close those over 10 months old. And so on. By all means keep a list of them somewhere but don’t pretend they will be fixed.
The only real debate are around category #2. We keep these on file in the hope that the Bug Fixing Fairy will fix them one day. In the absence of the fairy any work will require time and people to fix. That means they need to fight against all the other #2s and all the new shiny stuff. It is the same people who fix bugs as make shiny new things. It is a choice. A choice made probably by someone with the title Product Owner or Product Manager.
Which means if that fix isn’t more valuable than everything else then it won’t be done. This is the same argument I use when I say “Nuke the backlog.” If the fix isn’t valuable enough to justify being done, then it waits in a queue. The longer it waits the less important it is, leave any #2 bug there long enough and it will transform into #3.
What do I do?
The whole “is it a bug or is it a change request?” discuss is an utter waste of time. Whatever you call it work is needed, it s work to do, that work costs, that work creates benefits – the cost and the benefits are independent on what you call it. Benefit should the overriding criteria.
So
1) Fix the bugs you think need fixing
2) Don’t pretend you will fix the others, throw the bug list away
Of course, throwing away the records does not fix the “bugs”, they still exist – the same way cockroaches seem to survive everything. But we are recognising that, like cockroaches, the cost of action is not justified. This is simple honesty, a list of 100 items that we pretend will be done one day is dishonest. If that honesty creates a debate then good.
I have more advice – and more subtle advice in my “Bug management strategies” which outlines six strategies for addressing bugs and can be found in my lesser known “Xanpan appendix: Management and Team“.