Previously I wrote about the types of bugs that might come up during a sprint and dealing with them. This post is more on the backlog of bugs your project may “acquire”.
Most software, if not all, has some kind of bugs. They crop up over time, causing users pain, maybe throwing errors, logic errors, but just overall just not letting your software do what it is trying to do.
After a while, you end up with a “bug backlog”. That is, of course, you aren’t fixing your bugs at the same or higher rate than they are coming in. If that is the case, then kudos!, but many applications end up having little nuances/bugs everywhere. Your backlog can grow quickly if you don’t do something about it. 100, 500, 1000+ bugs. What do you do?
There are two main things to do with your bugs. First off, prioritize them. 1, 2, 3, 4, 5, whatever scale you want. You need to separate the wheat from the chaff so to speak. You want to focus on the highest priority bugs first. Second, you want to make sure you have some kind of category for your bugs. Screen X, Screen Y, Workflow A, Workflow B, etc. That way, you can hone in on different areas of your application and “attack” those bugs. As an addition, you can maybe set the criticality of your bugs as well, but that isn’t completely necessary to start.
To Repeat: Prioritize and Categorize (and optionally Set Severity).
You should probably review new bugs on a weekly basis or some time interval to keep up with the bugs coming into your system. Some bugs are going to come in that are just end users using the system wrong (I always have Steve Jobs in my head saying “You are holding it wrong” here..) Then you have things you just might not care about fixing. You should close both of these bugs. Keep them in your bug system, but close them, and let the end users know what is up.
Other bugs that come through that are valid, should get the priority, category and severity ratings. You should also look at the existing backlog to see if there are existing bugs that are related or possibly duplicate. As an aside, I wish there were some better tools for doing this automatically, I have done some research and there are actually some scholarly papers on the subject. Maybe some systems have this built in, but the ones I have used havent.
You should try to keep your bug backlog down. Keep it groomed. The only way you are going to do that is to close bugs you aren’t going to fix, fix bugs that come in, and make your software more robust to avoid bugs in the first place. The latter is the hardest, but eventually you are going to have to fix some bugs.
There could be different approaches to fixing bugs. You could take one bug and make it one story, this is perfectly fine. You may take many bugs that are related, group them up and make one story, that works too. You may have a “hardening” sprint and just do bugs that sprint, maybe go the gamification route and add bug fixing bounties, there are endless options, but you are going to have to fix them, for a few reasons: to keep your software in tip top shape, and to keep your users happy.
If you end up ignoring your bug backlog for too long, you may just declare bug backlog bankruptcy. But once you start getting bugs in again, it will grow, you can’t keep ignoring it. It is like never taking the garbage out if you ignore it, it will keep piling up.
In the end, the best thing to do is come up with a systematic way to deal with your backlog, and stick with it. Make it a priority for everyone on the team to be conscious of the bugs and backlog and assist when needed in verifying bugs, finding dupes, entering bugs, fixing bugs, etc. Nobody likes buggy software, and software doesn’t like bugs either. It is a win-win.
