How to Estimate Technical Debt Work
Technical debt is one of the hardest categories of work to estimate. Unlike feature stories with defined acceptance criteria, debt work often starts with "we don't know how bad it is" as the premise.
The discovery problem
The biggest challenge with debt estimation is that the scope is often unknown until you're already in the middle of the work. A refactor of a "messy" module might take two hours or two weeks - and you often can't tell which until you've opened the code.
Use a spike first
For any significant debt item where the scope is genuinely unknown, start with a spike. Timebox it - say, 4 hours - and use it to map what needs to change, identify dependencies, and surface blockers. The spike output is a set of estimable tasks, not a delivered solution.
Separate discovery from delivery
Split the debt item into two stories:
- Investigation story: size this in hours, not points. "Spend 4 hours mapping the refactor scope."
- Delivery story: estimate this after the investigation, using the knowledge you've gained.
This prevents the anti-pattern of estimating delivery before you understand the work.
How much debt work belongs in a sprint
Most teams can sustain 10-20% of sprint capacity on debt work without it becoming the whole agenda (a capacity pool, like the one many teams use for bug fixes). More than that tends to mean either the codebase has a serious problem that needs dedicated attention, or the team is using "tech debt" as a way to avoid delivering features.
Making debt visible to stakeholders
When you estimate debt work, add a "cost of not doing this" note: what will the next feature in this area cost if the debt isn't addressed first? This translates technical language into business impact and makes the prioritization conversation easier.
Treating technical debt like any other story - with acceptance criteria and a clear definition of done - makes it estimable and deliverable rather than a vague ongoing obligation.