Skip to content
Back to Maintenance & LTS

Debt Payment Strategy

Decide how much capacity to spend on debt vs features, and how to structure paydowns so they stick.

Why

The two failure modes are paying no debt (the codebase rots until every feature takes 3x) and paying only debt (you ship nothing and the business dies). A payment strategy finds the sustainable middle: a fixed fraction of capacity (typically 20%) goes to debt, scheduled into every sprint so it actually happens. The strategy also prevents the common anti-pattern of a "debt sprint" — a quarter where you fix everything, which never happens because the business always needs features. Spreading paydown across sprints as a steady drumbeat is what actually shrinks the debt, because compound interest works in reverse: each paydown unblocks the next feature, which is faster, which frees more capacity for the next paydown.

When

When debt is identified and prioritized. Set the policy once, then live it every sprint.

How

1. Set a capacity allocation: 20% of sprint points to debt (configurable, but never 0)
2. Pull from the prioritized debt backlog's pay-now bucket each sprint
3. Timebox each paydown: if a debt item exceeds its estimate by 2x, stop and re-estimate
4. Pair debt paydowns with the feature they unblock — "pay D2 so feature X is 2x faster" builds buy-in
5. Track a debt burndown chart: total debt items / total estimated hours over time
6. Quarterly, adjust the %: if debt is growing, raise it; if it's stable and features are starved, lower it
7. Never zero-out debt to "celebrate" — a debt-free codebase is a sign you're not taking any new debt, which means you're not shipping

Example

# Sprint planning with 20% debt allocation
Sprint 42 capacity: 80 points
- Features: 64 points (80%)
- Debt:     16 points (20%) <- non-negotiable

# Debt tickets pulled from pay-now bucket:
- D7  auth bypass test     (2 pts)
- D2  payment test coverage (5 pts)
- D11 extract user repo     (8 pts)
- D14 remove dead flag      (1 pt)
Total: 16 pts debt

# Debt burndown (tracked in the sprint review)
Sprint 40: 47 items / 120h remaining
Sprint 41: 44 items / 108h remaining  (-12h)
Sprint 42: 40 items /  95h remaining  (-13h)  <- trend: down

# Pair paydown with unblocked feature (in the sprint review):
"Paid D11 (extract user repo) -> feature 'multi-tenant' was 8pts, now 3pts"

Common Problems

  • ⚠0% debt allocation every sprint because "features are urgent" — debt grows until a feature takes 3x and nobody knows why.
  • ⚠A planned "debt quarter" that never arrives — the business always has a more urgent feature, so debt is perpetually deferred.
  • ⚠Paying debt without measuring the unblocking effect — leadership sees cost but not benefit, so they cut the allocation.

Best Practices

  • ✓Allocate a fixed % (start at 20%) of every sprint to debt — non-negotiable, scheduled, not "if we have time."
  • ✓Pair each paydown with the feature it unblocks and quantify the speedup — this proves the ROI to leadership.
  • ✓Track a debt burndown chart in every sprint review — a downward trend sustains the policy; a flat one triggers a higher %.