Engineering guide

14 min read

Technical Debt Estimation: How Teams Should Handle It

Technical debt is easy to feel and hard to estimate. Most teams don't fail because they can't measure it — they fail because they're measuring the wrong thing.

Try Ibis Flow free

See estimation features

An engineering team reviewing a technical debt backlog on a whiteboard, with sticky notes grouped by severity and delivery impact

The debt is real. The question is what to do with it.

Ward Cunningham's original debt metaphor describes the future cost created when a team chooses a faster solution now instead of the right long-term design. Martin Fowler describes the "interest" as the extra effort paid every time the team works on features in a codebase that has accumulated internal quality problems.

That creates a practical problem: Engineers feel the friction directly. Product owners see features, deadlines, and customer requests. When the two sides meet in a planning session, the conversation becomes an argument — "the codebase is bad" versus "we need to ship" — and neither side has the language to resolve it. I've had that argument on both sides of the table.

This guide cuts through that argument. Not by giving teams one estimation method, but by matching the right method to the decision they're actually trying to make.

Why technical debt estimates almost always miss

Teams that struggle with technical debt estimation are usually making one of three recurring mistakes. Recognise yours before reaching for a method.

The three traps

Estimating the wrong thing

A two-day cleanup task may be low value. A two-week refactor may remove a major bottleneck from the next six months of product work. A static analysis tool may report 120 hours of remediation effort — but that doesn't mean the business should spend 120 hours now. Effort and value are not the same thing.

The emotional argument pattern

When debt isn't estimated, it becomes a cultural grievance. "The codebase is bad" versus "we need to ship." Without a shared language — cost, interest, risk, delivery impact — the conversation can't resolve, so it repeats. Engineering teams lose credibility. Stakeholders lose confidence.

Hidden debt inside feature estimates

If technical debt is never named, it gets buried inside feature estimates, making delivery look unpredictably slow. Alternatively, it becomes a separate technical backlog that everyone agrees is important but nobody ever prioritises. Both patterns end the same way: the interest keeps compounding invisibly.

The question that reveals the right method

Before reaching for any estimation technique, ask one question first: what decision are we trying to make? The answer determines which method is useful — and which ones will waste your time.

A layered model, not a single method

Teams should not use one universal estimation method for technical debt. Different types of debt, different decisions, and different stages of a product require different approaches.

The better approach is a layered model. Prevent avoidable debt through Definition of Done and engineering standards. Include local cleanup in the feature estimate when required to complete the work properly. Create explicit backlog items for material debt that needs prioritisation. Use static analysis and Technical Debt Ratio for code-level maintainability signals. Use economic estimation when debt affects delivery speed, risk, reliability, compliance, or roadmap options. Reserve fixed capacity when debt is continuous, systemic, or too fragmented to negotiate item by item.

The hypothesis underlying this guide: technical debt should be estimated only to the precision needed for the decision. No estimate should hide the trade-off. Over-precise estimates create false confidence.

Precision proportional to the decision

A rough economic case is more useful than a precise hour count when the decision is whether to invest in a major refactor. A backlog item with a clear outcome is more useful than an SQALE score when the decision is sprint prioritisation. Match the method to the stakes.

Five approaches to technical debt estimation

There is no single right method. These five options cover the full range of situations teams face — from sprint-level cleanup to strategic investment decisions.

Option A: Include in feature estimate

If the cleanup is required to deliver the feature properly, include it in the feature estimate rather than creating a separate technical debt item.

Option B: Estimate as backlog work

Create explicit technical debt items, refine them, estimate them, and prioritise them alongside feature work using your team's normal estimation method.

Option C: SQALE / Technical Debt Ratio

Use static analysis to estimate code-level remediation effort and track Technical Debt Ratio over time as an objective code-quality signal.

Option D: Economic estimation

Estimate principal, interest, risk, cost of delay, and future delivery impact. Gives stakeholders a business conversation rather than an engineering complaint.

Option E: Fixed capacity allocation

Agree a fixed allocation of team capacity for refactoring, hardening, infrastructure work, or debt repayment — without negotiating every item individually.

Option A: include debt in feature estimates

If the cleanup is required to deliver a feature properly, include it in the feature estimate rather than creating a separate technical debt item. This is the right default when the debt is local to the work being done.

When this is the right call

The debt is local to the feature being delivered
The cleanup is required to complete the work to the team's quality standard
The work is inseparable from the feature
The cost is small enough to absorb without visibility concerns

When to avoid it

Systemic debt that spans multiple areas — burying it creates a pattern nobody can see
When the same debt keeps inflating the same feature area sprint after sprint
When the cleanup is discretionary rather than required to meet Definition of Done

The Definition of Done principle

The Scrum Guide's Definition of Done principle makes this clear: work is not part of a usable Increment unless it meets the required quality measures. If the refactor is required to meet that standard, it belongs in the estimate — not on a separate backlog.

The failure mode here is invisibility. If every feature touching the same area keeps getting larger because the same debt is slowing the team down, the debt needs to be surfaced — not buried in a succession of inflated estimates.

Option B: technical debt as backlog work

This option treats technical debt as first-class backlog work. A technical debt item should have a clear outcome, an estimated effort, and a trigger condition that makes its priority clear.

Examples of well-scoped debt items

Replace the deprecated authentication wrapper before the vendor drops support
Split the overloaded reporting service — three unrelated responsibilities in one class
Add contract tests around the payment integration — it has failed silently twice
Remove duplicated validation logic from three separate modules
Migrate the risky dependency before support ends in Q3

What a good technical debt backlog item contains

The debt — what the problem is and where it lives
The affected area — which features or teams are impacted
The pain it causes — slowdowns, defects, onboarding friction, incident risk
The repayment action — what work resolves it
The estimated effort — relative size or hours as appropriate
The expected benefit — what gets better after repayment
The risk of doing nothing — what the compounding interest looks like
The trigger — when this should be prioritised (e.g. before next major feature in this area)

Story points are not fixed hours

Story points are relative estimates of size, complexity, effort, risk, and uncertainty — not time-boxed hour estimates. Technical debt items are often more uncertain than feature items. A "5-point refactor" may include unknown coupling, unclear test coverage, and significant discovery work. If the team needs concrete capacity planning for a remediation task, estimate hours separately as a planning input.

Option C: SQALE and Technical Debt Ratio

The SQALE method treats technical debt as the remediation cost of violations against a defined quality model. Static analysis tools like SonarQube follow this logic: technical debt is the sum of remediation costs, and Technical Debt Ratio compares that cost with the estimated development cost of the codebase.

Why static analysis is useful

It creates a continuous, objective signal. Instead of relying on developer persuasion, the team can show trends: maintainability debt is increasing; new code is introducing debt faster than old debt is repaid; one component has a significantly worse debt ratio than others. These are concrete, shareable data points that can anchor an engineering conversation with non-technical stakeholders.

Good uses of TDR

"This service has the worst maintainability trend and is on next quarter's roadmap — we should front-load the refactor."
"New code debt ratio is rising, which means our quality gate isn't strong enough."
"The top 20% of rule violations account for most remediation effort — target those first."

Bad uses of TDR

"The tool says 120 hours, therefore we must spend 120 hours now."
"The TDR is high, therefore we must rewrite the system."
"The component has many code smells, therefore it is the highest business priority."

The scope limitation

Static analysis mostly detects code-level maintainability issues. It does not reliably detect architectural debt, product design debt, data model debt, missing domain boundaries, team cognitive load, weak test strategy, unclear ownership, or brittle release processes. Use SQALE and TDR as a signal, not as the decision itself.

Option D: economic estimation

The most decision-oriented option. Economic estimation asks teams to quantify the principal (cost to repay), the interest (extra cost paid while the debt persists), and the delivery impact — then compare those numbers against the roadmap.

The questions economic estimation asks

What is the cost to repay the debt?
What interest are we paying while we leave it alone?
How often does this area change — what is the change frequency?
What future work does the debt slow down or block?
What defects, incidents, or compliance risks does it increase?
What product options does it foreclose?
What is the cost of delay if we do not address it now?

How this lands with stakeholders

✓ Effective

"This refactor costs about two weeks. We expect to touch this area in six upcoming roadmap items. Each change currently takes two to three extra days because of coupling and missing tests. If we don't repay it, we expect to pay more in interest than the refactor costs over the next two quarters."

✗ Ineffective

"The code is messy and the team wants time to clean it up."

When to use economic estimation

Architectural debt in high-change, high-value areas
Security or compliance risk that could trigger incidents or audit findings
Platform constraints that block roadmap features
Debt that repeatedly inflates estimates in an area due for significant investment
Reliability risks with measurable incident frequency or SLA impact

The weakness is overhead. Economic estimation requires evidence: delivery data, defect history, roadmap context, incident data, or a credible forecast. It earns its cost for material debt — it doesn't scale to every code smell. The method works best when the debt has already made itself visible — through incidents, recurring estimate inflation, or a blocked roadmap item. If you're still trying to prove the debt exists, a different method will be more persuasive.

Option E: fixed capacity allocation

The maintenance tax model. Instead of negotiating every debt item individually, the team and stakeholders agree that a fixed amount of capacity — expressed as percentage, story points, or days — is reserved for debt reduction, refactoring, test improvement, hardening, dependency upgrades, or operational toil reduction.

The rhythm advantage

Developers stop having to fight for every small improvement. The team builds a habit of paying down debt continuously. A healthy product needs a small allocation; a legacy platform under active change may need much more; a team recovering from years of neglect may need a temporary remediation campaign before returning to a background percentage.

Risks to manage

Without visible reporting, the allocation becomes a black box — stakeholders stop trusting it
Teams may spend the allocation on the easiest cleanup rather than the highest-value debt
A fixed percentage doesn't adjust automatically to release windows, incident recovery, or team composition changes
If stakeholders can't see what the allocation is buying, it becomes easy to cut

Making it transparent

A fixed allocation needs visible reporting to retain trust. For each sprint or quarter, the team should show: which debt item was addressed, which area it affected, why it was chosen, and what measurable improvement resulted. Even a lightweight summary — one paragraph or a few bullet points — creates the accountability that makes the allocation worth defending.

Comparing the five options

No single method is sufficient. Use this matrix to identify which approach fits the type of debt and the decision you're trying to make.

Criterion	A: In feature	B: Backlog	C: SQALE/TDR	D: Economic	E: Fixed capacity
Best for local cleanup	High	Medium	Medium	Low	Medium
Best for architectural debt	Low	High	Low	High	Medium
Code-level maintainability tracking	Low	Medium	High	Medium	Medium
Business prioritisation conversation	Low	Medium	Medium	High	Medium
Sprint planning integration	High	High	Medium	Medium	Medium
Makes debt visible	Low	High	High	High	Medium
Captures future delivery impact	Low	Medium	Low	High	Medium
Setup effort	Low	Low	Medium/High	Medium/High	Low
Risk of false precision	Medium	Medium	High	Medium	Low
Main failure mode	Hidden systemic debt	Vague cleanup backlog	Tool metric mistaken for business value	Analysis paralysis	Black-box maintenance tax

Best for local cleanup

A: HighB: MediumC: MediumD: LowE: Medium

Best for architectural debt

A: LowB: HighC: LowD: HighE: Medium

Code-level maintainability tracking

A: LowB: MediumC: HighD: MediumE: Medium

Business prioritisation conversation

A: LowB: MediumC: MediumD: HighE: Medium

Sprint planning integration

A: HighB: HighC: MediumD: MediumE: Medium

Makes debt visible

A: LowB: HighC: HighD: HighE: Medium

Captures future delivery impact

A: LowB: MediumC: LowD: HighE: Medium

Setup effort

A: LowB: LowC: Medium/HighD: Medium/HighE: Low

Risk of false precision

A: MediumB: MediumC: HighD: MediumE: Low

Main failure mode

A: Hidden systemic debtB: Vague cleanup backlogC: Tool metric mistaken for business valueD: Analysis paralysisE: Black-box maintenance tax

The matrix points to a blended approach. No single method is enough. Feature-adjacent debt belongs in the feature estimate. Discrete debt belongs in the backlog. Code-level debt benefits from static analysis and TDR. Strategic debt needs economic framing. Continuous debt needs reserved capacity.

Decision rules for every situation

Apply these rules directly. Each one names the condition and the right response.

If the work is required to meet the Definition of Done → include it in the feature estimate, not as optional technical debt
If the team deliberately takes a shortcut → create the repayment item at the same time as the shortcut
If the repayment item has no owner, no trigger, and no estimate → the team has created unmanaged debt, not strategic debt
If the debt is local to the feature being delivered → estimate it as part of that feature
If the debt is discrete and has a clear repayment outcome → create a normal backlog item and estimate it with the team's usual method
If the team uses story points → use them for relative size, complexity, risk, and uncertainty — never convert them to fixed hours
If the team needs capacity planning for a concrete remediation task → estimate hours or days as a separate planning input
If a static analysis tool reports remediation effort → treat it as a code-level signal, not a complete business case
If Technical Debt Ratio is rising on new code → strengthen quality gates, Definition of Done, review practices, and automated checks before arguing about major remediation
If a component has high TDR but rarely changes → do not automatically prioritise it above lower-TDR components that are central to the roadmap
If debt affects high-change, high-value, high-risk, or roadmap-critical areas → estimate repayment cost and expected interest
If the expected interest over the relevant roadmap horizon is greater than the repayment cost → prioritise repayment
If the debt creates security, compliance, reliability, safety, or major incident risk → treat it as risk work, not optional cleanup
If stakeholders reject repayment → make the trade-off explicit: slower delivery, higher defect risk, reduced predictability, or blocked options
If the team spends too much time debating small debt items → reserve fixed capacity and report outcomes
If fixed capacity becomes a black box → add lightweight reporting: debt item, affected area, reason, before/after signal, expected benefit
If the product area is being retired and the debt does not create operational, security, or compliance risk → defer repayment by default
If the system is so degraded that normal feature work is no longer predictable → stop treating small background cleanup as sufficient and create an explicit remediation plan with business sponsorship

Use the method that fits the decision

Technical debt estimation should not be a guessing game, and it should not be a single metric applied regardless of context. The teams that handle debt well are not the ones with the most sophisticated tooling — they're the ones who know which question they're trying to answer before they reach for an estimation method.

For local debt, include it in the feature estimate. For discrete debt, create backlog items. For code-level debt, track remediation cost and TDR. For strategic debt, estimate cost, interest, risk, and cost of delay. For continuous debt, reserve capacity and report the return.

The goal is not perfect measurement. The goal is to make technical debt visible enough that teams and stakeholders can choose deliberately — instead of paying hidden interest forever.

Ibis Flow's estimation tools support the conversations that make debt repayment decisions stick — from structured planning poker sessions to stakeholder prioritisation with full audit trails.

Better estimation starts with better conversations

Ibis Flow brings your whole team into estimation and prioritisation — with Planning Poker, stakeholder input tools, and AI-powered insights that surface the context you'd otherwise miss.

Start free trial

See estimation features