Technical debt
The implied future cost of rework caused by choosing an easy or quick solution now instead of a better approach that would take longer.
What it means
Technical debt is a metaphor, not a formal Scrum concept, describing shortcuts in code, architecture, or design taken under time pressure that accrue 'interest' in the form of slower future development.
Some technical debt is a deliberate, reasonable trade-off, taken with eyes open to hit a deadline; problems arise when it accumulates silently and is never repaid, degrading velocity and quality over time.
Common mistakes
A healthy Definition of Done and regular refactoring inside Sprints, rather than a separate 'tech debt Sprint,' are common ways Scrum Teams keep debt manageable.
Example
The team ships a hardcoded configuration to hit a launch date, then logs a backlog item to replace it with a proper settings page.
Where technical debt comes from in Scrum
Most debt in a Scrum Team is not recklessness. It comes from a thin Definition of Done, from scope being squeezed into a Sprint late, from a design decision that was correct when the product was smaller, and from skills the team has not had time to build.
Scrum does not remove debt. It makes the cost visible faster, because a team that cannot get an Increment to Done in a Sprint feels the interest payment every two weeks.
How Scrum Teams pay it down
- Write the debt as Product Backlog items with the effect it has, so the Product Owner can order it against features instead of guessing.
- Strengthen the Definition of Done so new work stops adding to the pile.
- Refactor inside normal Sprints rather than saving up for a separate debt Sprint that keeps getting postponed.
- Use the Sprint Retrospective to look at which part of the system keeps slowing the team down, not just at process friction.