A lot of places where I end up have a bug backlog; usually around 200-800 defects features and other assorted stuff in there. But mostly bugs.

This creates an interesting dynamic, first of all trying to attack the backlog leads to analysis paralysis. Trying to go through 200+ items to find the most important one is not that feasible and without some order the developers will spend more time browsing for their next bug than fixing it. Setting a goal of resolving the backlog is usually meaningless because it can’t be translated into concrete useful steps. Developers ask for a code freeze for a month to just fix bugs, and business is usually not very interested in that. In the end it steadily grows and few and people come to accept it.

I think that a lot of this has to do with how the backlog is framed. First of it is accepted that you have one, it is even expected that you have software that helps you track them, and that there are reports, meetings and even departments dedicated to managing this backlog. It is also framed as a point in the now, it is a point measurement that often has no future or past reported with it.

A bug backlog to me is like carrying a balance on your credit card. It is the result of actions and gives you a point in time measurement of where you are at financially or in developer terms Stability. So the steps for getting out of bugs are similar to getting out of debt.

The most important thing is change.

How did the total chance over time, put it into excel and put some regressions on it to predict the future. How long until you would double your current troubles, how long until you hit the next nice & big round number. Try and create a prediction of the future and use that prediction as your baseline to improve against.

This means that if your group generates 20 bugs a weeks and you go to 15 bugs a week there is an accomplishment that can be celebrated. It isn’t good, but it’s better.

There is an important reason to attack the rate rather than the total. It is like a car traveling in the wrong direction at 65 mph (km/h) and you set a goal of going backwards 100 ft. putting the car in reverse isn’t really an option, you first need to break, change gears to reverse and then speed up again. The same needs to happen to the bug backlog. You first need to generate fewer bugs, then you need to make sure that bugs that are fixed stay fixed, and then you can comb through the back log to get them resolved.

Focusing on the rate focuses on behaviors. It focuses on evolution, sustained change rather than revolution.

Revolution takes a lot of energy, and quite often you need that energy to keep getting the new requests done.

Celebrate that a team prevented 500 bugs in the last 6 months as compared to their previous track record.

As to how to change the behaviors, chances are that the team already knows. Find the members that have good output and low bug rates and find how they do it. Every team is different, every company is different. There is no new technology that will fix this, there is no magic pill that someone can sell you. Mind you that this won’t stop people from selling them to you, an on occasion they might even work. But in general it faces “adoption” problems and falls short of expectations.

Find what already works and embrace it.