Lately I've been researching how engineering teams manage their tech debt. I have collated responses from just over 20 teams on how they manage tech debt in their work. Read on to learn how the best teams do this.
From the data, there were broadly 3 techniques that emerged and the technique depended on how much effort would be required to fix an issue.
1. Refactor as you go
For small issues in code these are things that engineers can and should do as they go along. They viewed this as part of the work of engineers and falls under the concept of leaving the campground cleaner.
2. Refactor and then start
Where a larger refactor is needed this would be raised in planning or estimation sessions and incorporated into the estimate when some work would be done on the affected area. This meant that the tech debt didn't need to be prioritised separately alongside product features. It was also viewed as just part of the work that needed doing by the Product Owner.
3. Allocated time or capacity
A popular approach for larger pieces of work that needed to be prioritised alongside new features, was to use some kind of allocation of time or capacity. The various approaches taken were as follows:
- a defined number of points per sprint
- a whole week or sprint once every n sprints or once a quarter
- a percentage of team time
- one team has an annual code freeze during which they will work on tech debt or housekeeping tasks
For these larger pieces of work, all the teams reported some degree of challenge of having to explain or make the case for working on tech debt.
However, there was one little gem that stood out from a number of teams that were most successful in getting tech debt prioritised.
They don't refer to it as tech debt.
They’ll describe the impact that the tech debt has in business terms.
Time and money. The effect on customers or sales.
"Silent failures in the billing service caused 4 hours of downtime last month"
"Slow page load times in the dashboard view cause drop-off during trials, reducing conversion from freemium to paid"
That's how they get it prioritised, and you can too.
👋 I am building Velocity Pilot, a dashboard for engineers and engineering managers to help them explain the impact of tech debt on their work.
I am committed to building out in the open and will share progress on Dev.to. Including what is working and what is not working. Follow me as I go solo from 0 to 1000 users in 6 months. 🚀
Top comments (0)