Debt-to-Feature Ratio Calculator
Every team argues about how much of the sprint goes to technical debt, and almost every team settles on a number someone half-remembers from a blog post. Enter what your debt actually costs you per sprint and how far ahead you are planning, and this tool calculates the split that produces the most feature output. Runs entirely in your browser.
The debt-to-feature ratio is the share of sprint capacity a team spends paying down technical debt instead of shipping features. The familiar answer is 20%, and it is folklore — nobody defends it with arithmetic. The defensible answer depends on three things you can measure: the capacity you already lose to the debt you carry, how fast new debt accrues under delivery pressure, and how many sprints you are actually planning for. Set those below.
1 — Your team
2 — Where capacity leaks today
Estimate these from your tracker and pipeline, not from feel — unplanned bug work as a share of closed items, time lost to flaky or slow pipelines, and the extra effort a change costs in your worst-understood module.
3 — Today's split and the pressure you are under
4 — What your scan surfaced
5 — The split that maximizes feature output
One sprint at the recommended split
Debt paydown Feature work delivered Lost to drag
Your inputs stay in your browser (local storage only). Nothing is uploaded.
How the recommendation is calculated
Capacity per sprint is developers × sprint days × 0.8 for a realistic focus factor. Your three leak sliders add up to drag — the fraction of remaining capacity that disappears into rework, friction and comprehension cost before anything ships. The tool then simulates every allocation from 5% to 60% across your horizon. Each sprint, paydown does two things — it works down the drag you already carry with diminishing returns and an irreducible floor, and it suppresses new accrual, which is the part most debt arguments ignore. Delivery pressure pushes accrual back up in proportion to how much feature work you are forcing through. The recommended split is the allocation with the highest cumulative feature output over the whole horizon plus the state it leaves behind, valued over an equally long continuation — not the one that feels responsible. That last term matters: a model that stops counting at the horizon will always under-invest in the final sprints, for no reason other than that it stopped looking. The search stops at 5% because below that a team cannot absorb even the debt it creates in the same sprint. If the optimum lands on that floor while your drag is high, the tool says so plainly — it means no allocation repays inside the window you have given it, which is a finding about the horizon rather than about the code.
The standard objection to debt paydown is that the team is too far behind to spare the capacity. Run the numbers and the opposite falls out: because paydown removes a proportion of the gap between current drag and the floor, the absolute capacity recovered per sprint is largest exactly when drag is highest. A team losing 35% to drag recovers more in three sprints than a team losing 12% recovers in ten. The teams that say they cannot afford to stop and fix things are the teams for whom stopping pays back soonest — and the teams comfortable enough to schedule a refactor sprint are usually the ones who need it least.
When an LLM-powered analyzer surfaces 400 items instead of the 40 a human review would have found, the instinct is to raise the debt allocation to match. That is the wrong reading. Discovery got cheap; absorption did not. Ten times the findings against unchanged capacity changes how long the queue takes to drain, and almost nothing else — which is why the item count in this calculator moves the burn-down figures but barely moves the recommended split. Raise the ratio when your measured drag rises. Do not raise it because a tool got louder.
Run it twice at the same drag — once at a 6-sprint horizon, once at 26 — and take both numbers into your next planning conversation. If the recommended split swings hard, you have not found a debt problem. You have found a horizon problem, and it belongs with whoever sets the targets rather than with the team.
A ratio is an allocation, not a decision. It tells you how much capacity to protect; it says nothing about which items deserve it. Pair it with an explicit ordering — debt sitting under the code you are about to change is worth many times the same debt in a stable module — or you will spend a defensible percentage on findings that were never in your way.
Drag reduction, accrual and the irreducible floor are modelled with a smooth diminishing-returns curve calibrated to typical delivery data. Real codebases move in steps, not curves: one bad module can carry most of the drag, and clearing it can shift the picture faster than any model predicts. Use the output to frame the conversation and set a starting allocation, then adjust from what your own sprints show over the next quarter.
Looking for more tools? Browse all product management calculators.
Frequently asked questions
What is the debt-to-feature ratio?
It is the share of a team's sprint capacity that goes to technical debt paydown rather than new feature work, usually written as a pair such as twenty to eighty. It is the one number that makes the debt conversation concrete, because it turns an argument about principles into an argument about capacity that a Product Owner can actually decide.
Is twenty percent the right amount of capacity for technical debt?
Twenty percent is folklore, not analysis. The right share depends on how much capacity the team already loses to the debt it is carrying, how fast new debt accrues under delivery pressure, and how far ahead the organisation is genuinely planning. Teams with heavy existing drag and a long horizon should invest far more than twenty percent, and teams with clean code and a short runway should invest less.
How does the calculator decide the recommended split?
It simulates every allocation from five to sixty percent across your chosen horizon and picks the one that delivers the most cumulative feature output. Each sprint, paydown both works down the drag already present, with diminishing returns and an irreducible floor, and suppresses the new debt that delivery pressure would otherwise add. The recommended figure is the allocation where those forces produce the largest total feature throughput.
Why does the planning horizon change the answer?
Paying down debt costs capacity now and returns it later, so the payback depends entirely on how many sprints you are counting. Over six sprints the arithmetic often favours starving debt, and over twenty-six it rarely does. This is why organisations run on quarterly targets tend to accumulate debt rationally rather than carelessly, and why the horizon is an input rather than a fixed assumption.
What counts as capacity lost to technical debt?
The calculator asks for three measurable leaks: unplanned rework and defect fixing, friction in build, test and environments including flaky pipelines, and the comprehension cost of working in code that is hard to read or onboard into. These are observable in your tracker and your pipeline, which makes the input defensible in a room where someone will challenge it.
My AI scan found hundreds of items, so should the ratio go up?
Not automatically. An automated scan increases the number of findings, not the capacity available to absorb them, so a larger backlog of flagged items mostly changes how long the queue takes to clear rather than what share of the sprint is worth spending. Raise the ratio when the measured drag rises, not when the scan output grows.
Can the debt-to-feature ratio ever be zero?
In practice, no. The calculator will not recommend below five percent, because a team spending nothing cannot absorb even the debt it creates in the same sprint. Sustained at zero, drag compounds until it consumes more capacity than any allocation would have cost, which is the mechanism behind teams that mysteriously slow down without any change in headcount. A short spell at zero is defensible only when the code has a known end date, such as a throwaway prototype or a system already scheduled for replacement.
Does this calculator save my data?
Your inputs are stored only in your own browser using local storage, so they survive a refresh and never leave your device. Nothing is uploaded to a server and no sign-up is required. Use the Reset button to clear everything and restore the defaults.