Scrum guide · Artifacts and practices
Technical Debt in Scrum: How to Spot and Manage It
Technical debt is the future cost of shortcuts taken today: rushed code, missing tests, outdated tools. Like financial debt, a little can be useful, but unmanaged it slows every Sprint.
Key takeaways
- Technical debt is the future cost of today's shortcuts.
- Make it visible in the Product Backlog.
- Prevent new debt with a strong Definition of Done.
Where it comes from
- Deadline pressure leading to shortcuts.
- A weak Definition of Done.
- Missing automated tests.
- Outdated libraries and infrastructure.
- Knowledge held by one person.
- Requirements that changed after the design was built.
Signs of growing debt
- Falling or erratic velocity.
- More defects escaping to users.
- Simple changes taking longer.
- Developers reluctant to touch certain areas.
Managing it in Scrum
- Make it visible: add debt items to the Product Backlog with a clear description of the cost.
- Strengthen the Definition of Done so new debt isn't created.
- Reserve capacity each Sprint, for example a share of the team's work, for debt reduction.
- Refactor continuously as part of normal work.
- Discuss it at the Sprint Review so stakeholders understand the trade-off.
Explaining debt to stakeholders
Frame debt in business terms: "This area takes three times longer to change and causes most of our production incidents. Investing two Sprints would speed up all future work here."
Free templates for this topic
Frequently asked questions
Who decides when to pay down technical debt?
The Product Owner orders the backlog, informed by Developers who explain the cost of the debt.
Is all technical debt bad?
No. Deliberate, short-term debt to learn quickly can be wise, as long as it is tracked and repaid.
What is technical debt?
The future cost of choosing a quick or easy solution now instead of a better one. It shows up as slower changes, more defects and riskier releases.
Who coined the term technical debt?
Ward Cunningham introduced the debt metaphor in 1992 to explain to business stakeholders why refactoring was needed.
How do you measure technical debt?
There is no single measure. Teams use signs such as time to make simple changes, defect rates, code analysis tools and the size of debt items on the Product Backlog.
Should technical debt go on the Product Backlog?
Yes. Making debt visible as Product Backlog items lets the Product Owner weigh it against new features.
How much time should a Scrum team spend on technical debt?
There is no rule. Many teams reserve a portion of each Sprint's capacity for it, adjusting based on how much the debt is slowing them down.
How does the Definition of Done prevent technical debt?
A strong Definition of Done, including tests, code review and documentation, stops shortcuts from becoming part of the Increment.
How does refactoring reduce technical debt?
Refactoring improves the internal structure of code without changing its behaviour. Doing it regularly keeps technical debt from building up.
Is technical debt only a software problem?
The term comes from software, but similar debt exists elsewhere, such as outdated processes, undocumented knowledge or quick fixes in content and data.
How do you convince stakeholders to pay down technical debt?
Explain it in business terms, such as how much slower changes are or how many incidents it causes, and show the expected gain from fixing it at the Sprint Review.