Independent educational resource. Not affiliated with CAST, SonarSource, or any code-analysis vendor. Data sourced from CISQ, Stripe, McKinsey, and DORA reports.
Five capacity allocation models, with formulas, conditions where each works, and worked examples for a 20 person team. Pick by context, not preference.
The most common starting point. Reserve a fifth of every sprint, every sprint, for debt work. Predictable, easy to communicate, easy to track.
Moderate debt (TDR 10 to 20%), stable team, leadership accepts the case
20 person team, 200 sprint hours, 40 hours per sprint reserved for debt. Two engineers focus, or four engineers part time.
A full debt sprint every quarter. Heavier per occurrence than the 20% rule, but progress is more visible because the entire team focuses.
High debt (TDR 20 to 50%), strong leadership, clear remediation backlog
20 person team, 5 weeks per quarter focused on debt. About 1,000 engineering hours per quarter on remediation.
Steady allocation between dedicated sprints. Catches incremental opportunities while preserving momentum on larger initiatives.
Most contexts, especially when you cannot predict the right pure model
20 person team, 30 sprint hours per sprint plus 200 hours per quarter from dedicated sprint. Total 1,160 hours per quarter.
Pause new feature work entirely until debt back below threshold. Wartime governance, not steady state. Use when other models have failed.
Critical debt (TDR above 50%), disciplined team, leadership backing the rule
20 person team, all 200 hours per sprint on debt until TDR drops below 25%. Typical duration 4 to 8 weeks.
Allocation scales with debt level. 10% at TDR below 10%, 20% at TDR 10 to 20%, 30% at TDR above 20%. Self correcting, harder to game.
Mature teams with reliable TDR measurement, sponsorship for variable budget
20 person team. At TDR 18%, allocate 36 hours per sprint. As TDR drops, allocation drops with it. As TDR rises, allocation rises.
| Debt level | Recommended model | Allocation | Expected duration |
|---|---|---|---|
| Below 10% TDR (A or B) | Boy Scout plus 10% rule | 10% of sprint capacity | Steady state |
| 10 to 20% TDR (C) | 20% rule | 20% of sprint capacity | Steady state |
| 20 to 35% TDR (D) | Hybrid, 15% plus quarterly | 15% plus dedicated | 12 to 24 months |
| 35 to 50% TDR (D) | Dedicated debt sprints | 1 in 5 sprints full | 18 to 36 months |
| Above 50% TDR (F) | Debt ceiling pause | 100% until threshold met | 1 to 6 months |
The 20% figure comes from a heuristic, not a hard study. It is large enough to make measurable progress without disrupting feature delivery rhythm, and small enough that leadership tolerates it. Empirically it holds debt at a stable level for moderate codebases. Below 15% allocation, debt grows. Above 30% allocation, feature delivery suffers. The 20% number sits in the middle of that band.
Tag every Jira ticket with debt or feature. At sprint end, tally debt hours actually delivered. Compare to allocated. Report adherence as a leading indicator. Below 70% adherence over multiple sprints signals the allocation is being absorbed by feature pressure, which means either the allocation is too small or the discipline is too low.
Better than not doing debt work at all, worse than coordinated allocation. Self directed debt time tends to fix small irritants rather than the structural debt that compounds. Best practice: allocate engineer hours, but prioritise the work centrally based on the eight dimension assessment results.
Build a 10% emergency buffer outside the debt allocation. The 20% rule then becomes 70% feature, 20% debt, 10% buffer. When emergencies arrive, they consume the buffer first. The debt allocation only gets touched when buffer is exhausted, which is the signal that the team is in firefighting mode and should escalate.