In response to my request for questions along the lines of what do I do when … ? Jo asked:

What do I do when the defect backlog keeps growing with low impact (and low priority) defects and nobody seems to pay attention to them as we have more important features (or medium/high) priority defects to deal with? Should we deal with it or just stop logging low impact defects?

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:

1. Do nothing
2. Filter out the noise
3. Stop logging low impact defects
4. Close off low impact defects
5. Prune the backlog
6. Batch the defects
7. Blitz the defects
8. Fix some every sprint
9. Automate the tests

1. Do Nothing

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.

2. Filter out the noise

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.

3. Stop logging low impact defects

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.

4. Close off low impact defects

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.

5. Prune the backlog

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.

6. Batch the defects

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.

7. Blitz the defects

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.

8. Fix some every sprint

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.

9. Automate the tests

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.

This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.