Is your team paying off technical debt in every sprint?

The sprint review became a déjà vu. The team committed to five stories, closed three, and two were "almost done." No one failed. No one shirked. Things simply took longer than expected.

When this happens once, it's an optimistic estimate. When it happens three sprints in a row, there's something else going on.

That something, in most cases, has a name: technical debt. Not the obvious debt—the one everyone points out but no one fixes—but the invisible one. The one that manifests as slowness, as unforeseen events, as hours that disappear without anyone knowing exactly where they went.

Why technical debt doesn't appear in your backlog

Most teams don't explicitly track technical debt. There's no ticket that says "wasting four hours understanding a module that no one documented." Nor one that says "redoing half the work because an outdated dependency is causing conflicts."

Those hours get lost within the product tickets. A story estimated at five points ends up taking eight, and no one investigates why. The team assumes they misestimated. The product owner assumes the team is slower than it should be.

According to DORA's State of DevOps report , high-performing teams spend less than 15% of their time on unplanned work. Teams with high technical debt can exceed 40%. This difference doesn't appear on any velocity chart. But it explains why the roadmap falls behind sprint after sprint.

The first problem with technical debt in delivery is not that it exists. It's that nobody measures it.

Signs that you're paying interest

You don't need a code audit to detect that technical debt is impacting delivery. There are signs that any product owner, engineering manager, or CTO can identify by observing the team's day-to-day operations.

Sprint velocity is decreasing for no apparent reason. The team hasn't changed, the scope is similar, the technologies are the same. But each sprint delivers less. The velocity curve is declining gradually, not abruptly.

It's like a dripping faucet: you don't notice it until you see the water bill.

The estimates consistently fall short. Everything takes longer than expected. Not 10% longer—50% or even 100% longer. And not because the team is miscalculating, but because each ticket carries a hidden cost that remains unseen until someone opens the code.

Bugs appear in areas no one touched. You change the payments module and email notifications break. That indicates hidden coupling: modules that depend on each other in ways no one documented or anticipated. It's one of the most expensive forms of technical debt because it turns every change into a gamble.

The team dedicates time to "research" before they can even begin working. If, before developing a feature, the team needs two days to understand the existing code, read old commits, and talk to the person who wrote that module three years ago, you're paying the price. That time spent researching isn't development; it's the toll of the debt.

Pull requests grow without a corresponding increase in scope. A two-point story generates an 800-line pull request because implementing the change required moving, renaming, and correcting code around it. The length of the pull request doesn't reflect the complexity of the feature, but rather the complexity of the debt.

How to measure the real impact on delivery

Detecting the signs is the first step. But to act, you need to quantify. You don't need a sophisticated system. Simply measure a few things over three or four consecutive sprints.

Ratio of planned vs. unplanned work

Of all the work your team does in a sprint, how much was in the plan and how much came about on the fly? Urgent bugs, fixes needed to move forward, unforeseen research, adjustments for broken dependencies.

All of that is unplanned work.

If unplanned work consistently exceeds 25-30% of the sprint, technical debt is likely the cause. Measuring this is simple: at the end of each sprint, classify completed tickets as "planned" or "emergent." After three sprints, you'll have a trend.

Cycle time by story type

Cycle time —the time from when someone starts working on a ticket until it's in production—is one of the most revealing indicators. But the absolute number doesn't tell you much. What matters is comparison.

If user stories in new modules (clean code, no legacy code) have a cycle time of two days, and user stories in older modules take an average of six days, the difference is pure technical debt. It's not that one module is more conceptually complex; it's that the code makes everything slower.

Tools like Jira, Linear, or Shortcut already track cycle time. You just need to segment by product area. If your team works with Django as a backend, for example, you can compare the cycle time of legacy modules against the latest ones.

Ticket expansion factor

Measure the difference between the original estimate and the actual effort. If a ticket estimated at 3 points ends up costing 8, the expansion factor is 2.6x. Calculate the average per sprint and per area of ​​code.

A consistently higher expansion factor than 1.5x indicates that the estimates aren't wrong: it indicates hidden work that can't be anticipated until you open-source the code. That hidden work is technical debt manifesting itself.

Ticket reopening fee

How often is a ticket that was previously closed reopened? A high reopening rate—above 10-15%—suggests that the code is fragile, the tests are insufficient, or the changes have unexpected side effects. All of that is technical debt.

The traps that disguise the problem

Technical debt in delivery is especially dangerous because teams and organizations develop unconscious mechanisms to conceal it.

Reduce the scope instead of questioning the speed. If the team is delivering less, the easy solution is to plan less. The sprint adapts to the reduced speed, and the problem disappears from view. But it hasn't disappeared: you've simply normalized your team delivering half of what it could.

Confusing activity with progress. Developers are busy, pull requests are moving, dailies report advancements. But the product barely changes. There's a lot of movement and little progress. If you were to measure how many lines of code in the sprint are new functionality versus forced maintenance, the result would surprise you.

Blame the estimates. "We estimated incorrectly" is the default explanation when something takes longer than expected. And sometimes it's true. But if the estimates consistently fail in the same direction and in the same areas of the code, the problem isn't the estimation itself.

Normalize bugs as "part of the process." All projects have bugs. But if your team spends more than 15-20% of the sprint fixing defects in existing code (not bugs in new features), the codebase is generating maintenance work that competes with product development.

What to do when you confirm the problem

If, after measuring for a few sprints, the numbers confirm what you already suspected, the next step isn't to open an epic "fix technical debt" ticket. It's to make the cost visible.

Translate debt into business language

The technical data convinces the developers. You need to speak a different language to the rest of the organization.

Don't say "we have high coupling and low coverage." Say: "Each new feature costs us 60% more than it should because the codebase is holding us back. Over the last three months, that's equivalent to X weeks of lost development time, which could have been spent on the features the business needs."

Stripe's 2018 report estimated that technical debt costs the global software industry $85 billion annually in lost productivity. You don't need such large figures: simply calculate how many hours your team loses each month to work caused by debt and multiply that by the cost per hour.

Create a debt heat map

Not all debt affects delivery equally. It involves two variables: frequency of modifications and the cost of each modification. Modules that are frequently modified and cost a lot each time are the priority.

Tools like CodeScene or SonarQube can generate these maps automatically. But even without tools, you can do it manually: ask the team which three files or modules they're most afraid to modify. The answer usually coincides with the areas of greatest debt.

Reserve capacity, don't negotiate it

Reducing technical debt shouldn't compete with features in backlog prioritization. It should have its own dedicated capacity. Allocating 15-20% of the sprint exclusively to technical improvements is a reasonable starting point.

If the debt is severe, you might need more. But start there. The important thing is that it's a firm commitment, not something you sacrifice every time an urgent feature comes up. Because there's always an urgent feature.

Measure improvement sprint by sprint

If you start investing in debt reduction, you need to demonstrate that this investment is producing results. Use the same metrics you used for diagnosis: velocity, cycle time, expansion factor, and reopening rate. You should see progress within four or five sprints.

If you don't see it, you might be tackling the wrong debt. Go back to the heat map and readjust your priorities.

When the team needs reinforcements

There's a recurring situation: the team knows exactly where the debt is, knows what it should be doing, but has no margin. 100% of its capacity is consumed by keeping the product running and delivering the bare minimum on the roadmap. There's no 15% to reserve because there isn't 15% available.

In such cases, an external team specializing in refactoring and systems modernization can handle debt reduction while the internal team remains focused on the product. It's not about relinquishing control; it's about expanding capacity for the time needed to climb out of the hole.

The key is for the external team to work in an integrated way with the internal team, not in parallel. They share codebases, share daily reports, and share criteria. Debt is reduced without fragmenting knowledge.

Debts are always paid.

You can ignore technical debt for a while. Sometimes for quite a while. But compound interest works the same way in software as it does in finance: the longer you wait, the more expensive it becomes.

The difference between a team that delivers consistently and one that's always behind is rarely talent. It's the state of the codebase they're working with. A good team with a clean codebase performs well. The same team with a delinquent codebase barely survives.

Measuring the impact of debt on your delivery service doesn't require expensive tools or complex processes. It requires ceasing to accept that "things take as long as they take" and starting to ask why. The data is usually there; you just need to look at it.