How often have you heard, “We have to fix the low severity defects now, or they will never get fixed!” – even when you know some high priority core functionality is still not working?

Stepping back, fixing low severity defects may not seem in line with the agile approach, when your backlog is tackled in priority order.  However, I like to think of defects as like droplets of oil: they aggregate, and collectively they can form a much bigger droplet and a more serious problem. This seems particularly true of consumability defects.

In this case, resolving low severity defects collectively is indeed a high priority task. But there are challenges:

• How can we track this aggregation – and hence prioritise defect resolution? Informally, through impact on user stories? Or through modifying defect tracking tools to recognise that defects are not necessarily isolated issues, but instead can mutually reinforce?
• Is it an “all or nothing” approach to resolving the aggregated defects, or should you pick off individual ones to shunt the overall problem back down the priority stack?
• Finally, I have interchanged “severity” and “priority” in this post. Purists will argue these are separate attributes for a defect – but I think this post demonstrates how they can be strongly correlated.