Technical Debt: How to Estimate and Prioritize
Every development team deals with technical debt. The problem isn’t having it — it’s not managing it. Ignoring technical debt is like ignoring credit card interest: the bill always comes, with penalties.
What Is Technical Debt
Technical debt is the future cost caused by sub-optimal implementation choices today. It includes:
- Untested code
- Architecture that won’t scale
- Outdated dependencies
- Missing documentation
- Superficial code reviews
- Duplicated code
How to Estimate Technical Debt
Known Debt
Specific refactoring items are estimated the usual way with Planning Poker:
- “Refactor the authentication module to use OAuth2” — 8 points
- “Add tests to the payment service (current coverage: 12%)” — 13 points
Invisible Debt
The cost of untracked debt is estimated through its impact on velocity:
“Over the last 3 sprints, 30% of our time was spent fixing bugs in the legacy module. That’s roughly 8 points per sprint in rework.”
Cost of Delay
“If we don’t refactor now, every new feature in this module will take 40% longer. Over 6 sprints, the extra cost will be roughly 48 points.”
How to Prioritize
The 20% Rule
Reserve 20% of each sprint’s capacity for technical debt. That’s enough to keep it from growing without sacrificing feature delivery.
Urgency Matrix
| High Impact | Low Impact | |
|---|---|---|
| High Risk | DO IT NOW | PLAN IT |
| Low Risk | MONITOR | ACCEPT |
Debt as a Blocker
If technical debt is blocking a high-value feature, it automatically becomes a priority. Example: “We can’t add 2FA because the authentication is entirely hardcoded.”
How to Communicate to Stakeholders
Translate to Business Impact
Don’t say: “We need to refactor the checkout code.” Do say: “Our current checkout code is responsible for 30% of reported bugs. Refactoring it will reduce bugs by roughly 15 per month and speed up new payment features by 40%.”
Use Analogies
“Just like a car needs preventive maintenance, our codebase needs refactoring. Driving on bald tires works fine — until it doesn’t.”
Show the Trend
A graph showing increasing bug counts or growing development time over sprints is more persuasive than any technical argument.
Paydown Strategies
Boy Scout Rule
“Leave the code cleaner than you found it.” Small improvements every pull request add up significantly over time.
Hardening Sprints
Every 3 to 4 sprints, dedicate an entire sprint to quality. It works, but it’s a hard sell.
Continuous Refactoring (Recommended)
Build refactoring into normal stories. If you’re touching a module, improve it. The story estimate already accounts for the improvement.
Technical Katas
One to two hour weekly sessions where the team voluntarily improves parts of the codebase. Good for morale, and good for the code.
Technical Debt Metrics
- Test coverage — percentage of code covered by tests
- Code duplication — % of duplicated code (SonarQube)
- Build time — how long CI/CD takes
- Bug rate — bugs per sprint per module
- Lead time — average delivery time (increases with high debt)
Conclusion
Technical debt is not optional — you have it regardless. The choice is between controlled debt (with a payoff plan) and uncontrolled debt (that will eventually paralyze your team). Reserve 20% of every sprint, communicate in business terms, and treat quality as a feature, not a luxury.