How to Manage Bugs Caused by Previous Technical Debt | David Tzemach
Updated: Mar 2, 2022
In Agile development, teams often have to handle bugs that do not directly relate to the commitments of the current sprint. Bugs of this kind can come from different streams (e.g. customer tickets, previous technical debt, etc.) and must be addressed based on the PO’s decision or sense of customer/business urgency.
To handle bugs arrived from one of those streams, the team can use three common approaches:
Using a dedicated story as a "bug container”
The team creates a dedicated story at the beginning of the sprint that contains a reference to a list of bugs that the team will handle as part of their commitment.
The most significant advantages of this approach are that it allows the team to understand the exact effort they need to invest in handling these bugs and to estimate and prioritize them as part of their sprint capacity.
Moreover, using a dedicated container for bugs, the team can determine how much of their time is allocated to handling tasks that do not add real value to the customer compared to what they deliver.
Bugs as backlog items
Bugs are added separately to the sprint backlog at the same level as stories. Then each bug is prioritized and estimated compared to the other stories in the backlog. Although these two approaches are effective, it still does not provide a solution for bugs that arrive from the field and must be handled due to their urgency.
Reduce team capacity and use a dedicated backlog
I worked with organizations that treated bugs as pure technical debt that should not be part of the team backlog, as they do not add any value. As a result, Product Owners and their teams created a dedicated bug backlog or, in some cases, even a Kanban board containing all those bugs.
The problem with this approach is that it still doesn’t provide a real solution for the basic thing that the team still need to invest their time in to handle those bugs. The creative solution was to automatically reduce the team capacity (usually by 10-20%, depending on the amount of work) to allow the team to focus on reducing technical debt.