Independent educational resource. Not affiliated with CAST, SonarSource, or any code-analysis vendor. Data sourced from CISQ, Stripe, McKinsey, and DORA reports.
Five strategies for reducing debt: the 20% rule, dedicated debt sprints, debt ceilings, the Boy Scout rule, and the Strangler Fig pattern. Each has specific conditions where it shines and predictable failure modes.
Each strategy has a clear formula, a context where it works, a context where it breaks, and a predictable failure mode. Pick by context, not preference.
Reserve 20% of every sprint for debt reduction. The most common starting point for moderate debt levels. Predictable, steady, and easy to communicate.
Moderate debt (TDR 10 to 20%), stable team, leadership accepts the case
Critical debt (allocation too small), undisciplined team (allocation drifts)
Allocation creep. Always one more critical bug to displace it.
Set entire sprints aside for debt work, typically quarterly. Strong sponsor buy in required because feature delivery pauses for the sprint duration.
High debt (TDR 20 to 50%), strong leadership backing, clear remediation backlog
Weak sponsor (next sprint becomes a feature sprint), no concrete backlog
Just one more feature sprint first.
Set a hard threshold (typical: TDR 10%, code coverage 70%, vulnerability count zero). When breached, all new feature work stops until back under. Extreme but highly effective.
Critical debt, disciplined team, leadership willing to back the rule
Process drift (the rule gets ignored), threshold chosen arbitrarily
Wartime governance, cannot be the steady state.
No allocated time, no ceiling, just a cultural norm: every PR improves the file it touches. Lowest overhead, slowest progress, best as a complement.
Healthy debt levels, mature team, code reviewers who enforce the rule
Standalone for high debt (too slow), low review rigour
Improvements scoped too small to dent structural debt.
Architectural strategy. Build new functionality alongside old, route traffic incrementally, retire legacy when usage hits zero. Best for monolith decomposition.
Architectural debt, rewrite cost too high, risk averse environment
Code level debt (wrong tool), no clear seams in the legacy system
Strangling stalls, both systems run forever.
All five strategies side by side. Pick the row that matches your context.
| Strategy | Speed | Feature impact | Stakeholder ask | Best for debt level |
|---|---|---|---|---|
| 20% Rule | Slow steady | Low | Light | Low to medium |
| Debt Sprints | Medium fast | High in sprint | Heavy quarterly | Medium to high |
| Debt Ceiling | Fast | Variable | Heavy | Critical |
| Boy Scout | Very slow | None | None | Low |
| Strangler Fig | Slow | Low feature slowdown | Architectural buy in | Architectural |
Five questions about your team and context, one recommended strategy with rationale.
What is your current debt level?
How strong is leadership buy in for debt work?
How disciplined is your team on process?
What is the shape of the debt?
Is your team headcount growing?
Answer all five questions to see a recommendation.
Four metrics tell you whether the strategy is working before the headline TDR moves.
The headline number. Slow to move, but the figure leadership tracks.
Deploy frequency, lead time for changes, change failure rate, MTTR. Reveal whether debt is impeding flow.
Self reported time on debt vs features. Fastest signal of strategy effect.
Sev 1 and Sev 2 incidents in the systems being remediated. Lagging indicator, but high signal.
The 20% rule is the most common starting point and the right answer for moderate debt levels. For TDR above 20%, dedicated debt sprints quarterly often outperform fixed allocation because they make progress visible. For TDR above 50%, only a debt ceiling halts the compounding fast enough. Research from CAST and DORA suggests teams allocating less than 15% experience steady debt growth, while teams above 30% sacrifice feature delivery without proportional gain.
It works when three conditions hold: leadership protects the allocation, the team has discipline to honour it, and the work is tracked separately from feature work so progress is visible. It fails most often because urgent features displace it sprint after sprint. Track your debt allocation as a formal capacity line, like vacation, not a soft target.
Debt ceilings work best when debt is already critical and the velocity tax is visible to leadership. They are wartime governance, not steady state. Set the ceiling, communicate it widely, hold the line for one to two quarters, then transition back to allocation when the team is healthy again. Permanent ceilings tend to be quietly relaxed.
Three steps. First, quantify the cost using the Financial Impact model. A specific dollar figure beats hand-waving. Second, frame as ROI not maintenance: the question is not whether to refactor but whether to spend $X to save $3X. Third, propose a specific strategy with measurable milestones, not an open ended commitment. The business case page on this site has a five slide template.
Four metrics. TDR or SQALE rating quarterly (the headline). DORA metrics (deploy frequency, lead time for changes, change failure rate, mean time to recovery) monthly. Velocity tax estimate from sprint retros. Incident frequency for the systems being remediated. Together these tell you whether the strategy is working before the headline TDR moves.