What is the best approach in dealing with a huge bug backlog? Currently we have a huge bug backlog and i was looking for an efficient way to deal/categorize/ how to manage the backlog?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
This is very common.
There are basically 3 parts to the problem:
I'll focus on part 3 - the cleanup - but if you don't do parts 1 and 2 you'll quickly be in a bad spot again (if you ever get out at all). If you want more info on Measure and Track then ask questions about those parts specifically for specific answers that can go into detail (and solicit a variety of answers of course). Also Kate's detailed answer has good info for those activities.
More specifically, for the cleanup, I would look to
In addition to Michael Durrant's excellent answer and the equally good comments, I'd suggest you consider a few things:
When I have worked on resolving bug reports in the past I found that the backlog was able to be shrunk due to a large number of people reporting the same bug. We wrote a similar bugs plugin for our app which searched all open bugs and recommended which ones to link as the same bug, then a new bug report was created automatically with details from all the customer submitted bug reports and the customer submitted bugs which where for the same bug where all linked together and related to the one bug, in one instance we where able to take nearly 1000 bug reports and reduce them to a single master bug report which had been duplicated so many times simply because the bug was in a frequently used feature which was bringing up an error display and our error display featured a "Report as Bug" button.
Faults are an inevitable part of software delivery. I only briefing touched on managing lists of faults in Agile Project Execution so it is well worth expanding on.
In fact defects is an area where software delivery, including agile software development, can get messy. Luckily there are ways to manage this mess or to avoid it altogether. Jo’s question hints at potential answers but there are others. In fact I know of at least nine common strategies for managing a growing fault list.
My strategies are:
Before deciding which option to take you’ve got to know who cares. Who cares that the product backlog is large? Product Owner? Developers? Project Manager? If nobody cares then it isn’t a problem.
Then there is, why do they care? Maybe your developers care because they see a lot of noise in the product backlog, things that they shouldn’t be working on. If that is the problem then just make sure the developers don’t see the low impact items until those items get prioritised. If your product backlog is electronic then you can use some kind of filtering for this. If the product backlog is cards on a wall, then put the non-prioritised cards somewhere else.
It might be your product owner who hates wading through low value defects when they prioritise the backlog. Filtering can help here too.
Maybe the tester cares because it makes the fault statistics look bad. In that case check where these figures are being reported and see if any anybody else cares. If the higher ups don’t care then persuade your tester not to care. Alternatively negotiate reporting something else, e.g. only high and medium impact defects and exclude low defects, or report number of defects in each category. This is also essentially a filtering solution.
If you have to do something to reduce the number of defects on the list then you can, as Jo suggests, just stop logging low impact bugs. The only trouble with ignoring low impact defects in this way is that throwing the card away doesn’t fix the problem. There is a risk that people will keep noticing the same faults and raising them again. None-the-less you might find that risk worthwhile.
This is a bit similar to not logging low impact defects at all. In this case you don’t fix the problem but decide it is never going to be fixed and just close the ticket. Same risk that it’ll be raised again, but might not matter.
Even if you retain the full list of defects you’ll have to prune the product backlog occasionally as the list will become stale. Over time, because of changes to the system, some items will become irrelevant. Irrelevant defects are just clutter and should be purged.
Another option is to batch related defects together. They might be low impact and low value individually but in combination their overall value will increase. For example you might group together a set of “email” defects and get the product owner to priortise these grouping rather than the individual items.
A common tactic is to blitz the defects. That means allocating the whole team to fixing defects for a sprint. This often happens immediately before a major launch.
It is also common to allocate a certain proportion of effort to fixing faults each sprint. I advocate giving the technical team time each sprint to fix technical debt and fixing faults can be rolled into that.
The last and best of the nine strategies is to push automated testing. The goal with automated testing is that all defects are addressed within the sprint thus the number of defects that need to be logged are vastly reduced. And the step of logging the defect can be often replaced by writing a new test.
If you don't have a big backlog then you don't need to deal with it. I think to manage what you have currently, in addition to all the good points already presented to you by others, you have to figure out the phase(s) most defects are injected too.
In my understanding of the Agile theory, defects are technical debt, you don't really allocate time in a sprint to work on technical debt. Each sprint has a clear goal -- working on stories. I know in reality teams may allocate resource on the side to tackle on technical debt, but this means it should at the same time take away resource from the sprint (lower velocity), and this is rightly so to avoid more defects injected due to lack of proper resource/time.
From my experience, unless your backlog is from legacy code (days before being Agile), you should look at your "done criteria" for your Agile stories. When a story is done, it should be "done done", not just code written ready for QA. If too many defects come our of these story, you should make sure necessary testing is in the storys' done criteria. Hopefully your backlog will shrink this way.