Add a "Best before" date to bug reports

You often hear Teams, Product Owners or Testing Managers complain that they have too many bugs to manage within their project. As both a Product Owner and a Tester I have my own pragmatic solution; Add a "Best before date" to every bug report and throw away the expired ones.

You are now thinking "why?". In a fast moving project the bug report, the steps to recreate and its impacts, are accurate at the time of report creation. But as the project progresses, the number of changes integrated into the code bases increases, the accuracy of the data within the bug report degrades. It could be the data is so degraded that bug no longer exists within the system and the report is a ghost of a dearly departed bug.

The "Best before date" scheme works based on the customer value impact of the bug. If the bug isn't fixed before the expiry date then the impact must be minimal (or perceived to be minimal) to the customer or it would have been given greater priority by the product owner. If an expired bug is reported a second or third time, then the bug is a higher value impact than initially identified and needs to be given a high priority. This is applying the Pareto Principle to the bug database.

The Pareto Principle is a simple idea, 80 percent of outcomes flow from 20 percent of causes. If you applied it to your projects story backlog, only 20% of the user stories provide 80% of the value. Now consider applying Pareto to your database of bugs, only 20% of your bugs represent 80% of the value impact to customers. The 20% of bugs are the ones you want to focus on championing and fixing, and the "Best before" concept aims to help you identify these by throwing away the other 80%.

Selecting the expiry time period for bug reports is subjective to your project. You could measure the time in weeks, months or sprints. You can also vary the length of time until expiry on severity rating of the bug. Just remember to not set the time period to long, otherwise you lose some of the value of the technique; I find a critical bug not fixed within a 3 months isn't that critical.

Now the suitability of this technique would depend on the context of your project. For example, It wouldn't work on projects with long release cycles as you would have bugs reports expiring before a release occurs, but in this case, you have bigger bottlenecks in your process than managing too many open bugs.