At each release or a push to production, we defer a set of bugs and add to our technical debt. Unless you keep aside time for fixing these issues, you will keep adding to your technical debt. This will become an issue sooner or later. But doing this is hard. It is easier said than done.
Setting aside time has been really difficult for me as I’ve tried to chase more strategic priorities with a 2-3 year payoff instead of fixing old bugs. I’ve also noticed that very few bugs that we’ve deferred ever come back to haunt us via user to user forums or through social media and have wondered if it even makes sense to go back and fix these bugs
So… what is the optimal number of deferred bugs or legacy issues that we should fix in a given 3-4 month release? Generally, for highly functioning and customer connected teams, this number is much less than what the product management team feels comfortable with at the time of shipping an update.
This means that product management teams can be stricter about the total number of bugs to reopen for fixing after a release has shipped. I believe that we will get much better results if we let the feature team or “squad” decide which bugs to reopen and fix in their area.
Once we have a list of bugs to reopen, it has not been easy to get these fixed in time for the next release. We’ve tried different strategies like:
- Assigning a bucket of bugs to the team and letting them fix the bugs over an 2-3 month period
- Prioritizing deferred bugs and letting the team fix as many as they can within a month after release
- Setting aside a 2 week period where the team only fixes bugs in the order of priority of the bugs
We have had the most success with option #3 since it gives a clear goal and time to the dev team to go after these bugs. This said, we still don’t get all of the bugs fixed since fixing long standing issues is not trivial, otherwise we would have fixed them already. Other options lead to teams fixing easier bugs rather than going after the hard, important ones.