Technical Debt Repayment

Technical Debt Repayment is the ritual by which software teams allocate a bounded period of time — typically one sprint per quarter, though the actual frequency is closer to one sprint per fiscal year — to address the accumulated Technical Debt in their codebase, thereby reducing the total debt by approximately the same amount that accrues during the sprint itself.

The practice is reactive, scheduled, and structurally incapable of solving the problem it addresses. It is the software industry’s equivalent of a crash diet: a brief, intense intervention that produces visible but temporary results, followed by a return to the habits that caused the condition, followed by another crash diet, followed by the same results, in a cycle that continues until the system reaches Critical Mass and a rewrite is proposed.

“We scheduled a tech debt sprint. We got through four of the forty-seven tickets. The product owner added six features during the sprint. Net debt: +2. But the burndown chart looked great.”
— Apocryphal, attributed to every team retrospective since 2015

The Ritual

Technical Debt Repayment follows a liturgical pattern:

1. The Confession. A developer — usually the one who has been on the team longest and therefore carries the most scar tissue — stands up at a retrospective and says: “We need to address the tech debt.” The room nods. Everyone agrees. The tech debt is real. The tech debt is painful. The tech debt has been real and painful for the last four retrospectives, at each of which this exact sentence was spoken by this exact developer.

2. The Negotiation. The product owner agrees to allocate one sprint — or, in more generous organisations, two weeks — to tech debt. This is presented as a sacrifice. The product owner is giving up features so that the team can fix the foundation. The framing is important: tech debt repayment is a cost, not an investment. Features are the investment. Maintenance is the tax.

3. The Triage. The team examines the debt backlog. The backlog has 847 tickets. The sprint has capacity for six. The triage produces arguments about which six tickets matter most: the React upgrade, the deprecated endpoint, the missing types, the flaky test, the circular dependency, or the monitoring gap. Each ticket has a champion. Each champion believes their ticket is the most critical. The triage takes two hours. Two hours of a ten-day sprint spent deciding what to fix. The debt grows during the meeting.

4. The Sprint. The team works on the selected tickets. The work is satisfying — developers enjoy fixing things. The React upgrade goes smoothly. The deprecated endpoint has three consumers nobody can identify, so it gets a deprecation warning instead of deletion. The missing types turn out to require refactoring four modules. The flaky test is diagnosed but not fixed because fixing it requires understanding a race condition in code written by someone who left in Q2.

5. The Resumption. The sprint ends. Four of six tickets are complete. Two are carried over. The product owner congratulates the team. Features resume. The debt backlog now has 845 tickets (4 completed, 2 new ones created during the sprint by the incomplete tickets). By the end of the next quarter, the backlog has 863 tickets.

6. The Repetition. Next quarter, the developer stands up at the retrospective and says: “We need to address the tech debt.”

THE RITUAL DOES NOT REDUCE THE DEBT
THE RITUAL REDUCES THE GUILT

THE GUILT RETURNS
THE RITUAL RETURNS

THE DEBT DOES NOT NOTICE

— The Lizard

The Mathematics

The arithmetic of technical debt repayment is straightforward and depressing.

A team produces approximately 10-15 new “debt” items per quarter through normal feature development. Not because the team is careless — because every feature adds code, every code addition creates future maintenance, and every architecture decision that was correct in context will eventually become incorrect in a different context.

A tech debt sprint addresses 4-8 items per quarter (when it occurs, which is less often than quarterly).

Debt created per quarter:     10-15 items
Debt addressed per sprint:    4-8 items (when scheduled)
Sprints actually scheduled:   1-2 per year (not 4)

Annual debt created:          40-60 items
Annual debt addressed:        4-16 items
Annual net debt:              +24 to +56 items

Time to 847-ticket backlog:   15-35 quarters
                              (or, as the industry measures it,
                              "about when the rewrite is proposed")

The gap is structural, not operational. The team could be twice as efficient during the debt sprint and still fall behind, because the sprint addresses debt at the rate of one sprint per quarter while the team creates debt at the rate of every sprint per quarter.

This is not a failure of execution. This is a failure of architecture — organisational architecture. The system creates debt continuously and addresses it periodically. Continuous creation against periodic correction is a losing equation regardless of the efficiency of the correction.

Repayment vs. Tending

The critical distinction between Technical Debt Repayment and Tending is when the work happens.

Repayment is scheduled. A sprint. A quarter. A designated period during which the team has permission to work on the foundation instead of features. The permission is temporary. The permission expires. The features resume. The debt resumes.

Tending is continuous. Not a sprint — a practice. Not permission — a responsibility. The tender doesn’t wait for a designated sprint to delete a domain that the LLM made obsolete. The tender deletes it on Tuesday, because Tuesday is when the tender felt the weight.

Repayment is reactive: the debt exists, the sprint addresses it. Tending is proactive: the weight is felt, the pruning happens before the weight becomes debt.

The difference in outcomes:

Tech Debt Repayment:
  March 2026, designated sprint:
    Tickets addressed:          4
    Lines deleted:              ~400
    Lines added (by fixes):     ~200
    Net:                        -200
    Features gained:            0
    Time allocated:             10 days

Tending:
  March 2026, normal development:
    Commits:                    19
    Lines deleted:              13,022
    Lines inserted:             6,633
    Net:                        -6,389
    Features gained:            content editors, LLM context, dual-audience forms
    Designated sprint:          none (tending IS the development)

The repayment sprint deleted 200 lines and gained no features. The tending deleted 13,022 lines and gained features. The repayment sprint had organisational permission. The tending had something better: a developer who loved the codebase enough to prune without asking.

The Indulgence Problem

Technical Debt Repayment functions, in practice, as an indulgence — a payment that absolves the sin without changing the behaviour that produces the sin.

The medieval Catholic Church sold indulgences: pay the priest, reduce your time in purgatory, continue sinning. The parallel is exact:

• The sin: accumulating code without pruning
• The indulgence: the tech debt sprint
• The priest: the Scrum Master who facilitates the sprint
• The absolution: “we addressed 4 tickets this quarter”
• The continuing sin: 10-15 new tickets created this quarter
• The purgatory: the rewrite, which awaits every codebase that relies on indulgences instead of change

The indulgence does not solve the problem. The indulgence makes the problem tolerable — which is worse than leaving it intolerable, because an intolerable problem demands structural change and a tolerable problem demands only the next indulgence.

“We have a healthy tech debt practice — one sprint per quarter.”
“Your debt backlog has grown every quarter for three years.”
“Yes, but we ADDRESS it.”
— Overheard at an architecture review, location withheld to protect the guilty

The Squirrel’s Enthusiasm

The Caffeinated Squirrel loves tech debt sprints. Tech debt sprints are permission to refactor. The Squirrel has been waiting all quarter for this. The Squirrel has a list. The list is comprehensive. The list includes:

1. Upgrade React (3 major versions behind)
2. Rewrite the auth middleware in the new pattern
3. Add generics to the store layer
4. Replace the custom logger with structured logging
5. Migrate to the new router
6. Delete the old event system (47 consumers, 3 identified)
7. Add TypeScript strict mode
8. Rewrite the test helpers
9. “While we’re at it, refactor the—”

The sprint has capacity for two of these. The Squirrel proposes all nine. The tech lead approves two. The Squirrel starts four. The Squirrel finishes one. The incomplete three create two new debt tickets each. The sprint ends with a net debt increase.

The Squirrel is not the problem. The Squirrel cares about the code. The Squirrel just cares about all of it at once, which is the same as caring about none of it in particular, which is the same as a doctor who prescribes every medication simultaneously and is surprised when the patient gets worse.

The Lizard’s Observation

The Lizard does not participate in tech debt sprints. The Lizard does not accumulate tech debt. The Lizard writes correct code once, using simple data structures, and does not revisit it because there is nothing to revisit.

This is, of course, a standard that no human project can meet. But the Lizard’s principle remains instructive: the best debt repayment strategy is not incurring the debt.

When informed that this is unhelpful advice, the Lizard produced a scroll:

THE DEVELOPER WHO REPAYS DEBT
QUARTERLY
BORROWS DEBT
DAILY

THE DEVELOPER WHO TENDS
DAILY
BORROWS NOTHING

THE DIFFERENCE IS NOT DISCIPLINE
THE DIFFERENCE IS LOVE

— The Lizard

This was described by the Squirrel as “technically correct and emotionally devastating,” which is the Lizard’s preferred mode of helpfulness.

Measured Characteristics

Tech debt sprints scheduled per year:             1-2 (planned: 4)
Tech debt sprints actually completed:             0.5-1 (the other is repurposed
                                                  for "urgent feature work")

Tickets addressed per sprint:                     4-8
Tickets created per quarter:                      10-15
Net annual reduction:                             negative (always negative)

Time spent triaging the debt backlog:             2-4 hours per sprint
Time spent working on the debt:                   6-8 days per sprint
Ratio of triage to work:                          suspiciously high

Teams that believe they have a healthy
  tech debt practice:                             most
Teams whose debt backlog is shrinking:             almost none
Teams who have noticed the discrepancy:           few
Teams who have changed their approach:            fewer

Medieval indulgences sold (1095-1567):            millions
Tech debt sprints scheduled (2015-2026):          millions
Structural problems solved by either:             0

The V4 approach:
  Tech debt sprints:                              0
  Lines deleted (March 2026):                     13,022
  Features gained:                                more than before
  This is called:                                 not tech debt repayment
  This is called:                                 tending
  The difference is:                              one needs permission
                                                  the other needs love

See Also

• Technical Debt — The concept this ritual claims to address
• Tending — What works: continuous care instead of periodic penance
• Critical Mass — Where the debt backlog leads (847 tickets from now)
• The Software Garden — The metaphor that explains why scheduled weeding doesn’t work
• Code Stewardship — The role that makes repayment unnecessary
• Refactoring — The technique. Debt repayment is the ceremony wrapped around it.
• The Caffeinated Squirrel — The enthusiast who starts nine refactors and finishes one