What is technical debt?
Technical debt is the accumulated cost of choosing a faster, less-clean implementation now in exchange for slower, more expensive future work. The metaphor (coined by Ward Cunningham, 1992) is intentional: like financial debt, you pay interest in the form of bugs, slowdowns, and rework until you "pay it down".
Where technical debt comes from
- Deliberate trade-offs — "ship now, refactor next sprint" to hit a deadline.
- Knowledge gaps — patterns chosen before the team knew the domain well.
- Decay over time — what was clean code in 2018 may be misaligned with the codebase of 2026.
- Skipped tests, docs, or types — quick to skip, expensive to add back.
Symptoms in your sprints
- Velocity trending down — same team, same effort, less output.
- Estimates blow out — small-looking changes routinely take 3× the planned effort.
- Bug recurrence — the same root cause keeps surfacing in new tickets.
- "Fear" stories — code areas nobody volunteers to touch.
How to manage it
- Track it explicitly — log debt items as backlog tickets, not unspoken team folklore.
- Reserve sprint capacity — many teams allocate 10–20% of every sprint to debt repayment.
- Tie repayment to feature work — pay down debt in modules you're already touching for a feature.
- Boy-scout rule — leave the file cleaner than you found it.
Common mistakes
- "Big bang" rewrites — almost always over budget and rarely finished. Refactor incrementally.
- Treating all debt equally — only pay down debt that's slowing the team now or near critical features.
- No visibility — debt that lives only in engineers' heads never gets prioritized against features.