Technical debt accumulation rate

Technical debt accumulation rate is the net debt a codebase adds in a period, expressed as a percentage of the development effort spent in that same period. If a team adds 400 hours of debt, clears 250 hours, and spent 3,000 hours on delivery, the net of 150 hours over 3,000 gives an accumulation rate of 5 percent. For every hour of work, the codebase got about three minutes deeper in debt.

The rate is the normalised cousin of raw accumulation. Net accumulation in hours tells you how much heavier the codebase got, but it scales with team size, so a 200-hour increase means something very different for a squad of three than for a department of fifty. Dividing by development effort strips out that scale and gives you a figure you can compare across teams, across quarters, and against a target.

The rate matters because it answers a sharper question than the raw number: is debt growing faster than the work that produces it? A growing team can post a rising hours figure while its accumulation rate falls, which is healthy. A shrinking team can post a falling hours figure while its rate climbs, which is not. The percentage is what keeps the trend honest as the organisation changes shape.

The rate divides net debt added by the development effort spent in the period, then multiplies by 100 to give a percentage. You need three inputs, all measured over the same window: new debt added, debt remediated, and total development effort. Consistency between periods matters more than absolute precision, because the rate is read as a trend against a target.

1. 1

   New debt added

   Sum the estimated remediation effort for every shortcut, untested change, and new code-quality issue created this period. Source candidates from static analysis, review comments tagged as debt, and tickets logged as deferred work.

2. 2

   Debt remediated

   Sum the estimated effort of every debt item genuinely resolved this period through refactoring, coverage, dead-code removal, or dependency upgrades. Exclude new feature work that merely happens to be clean.

3. 3

   Development effort

   Total the engineering hours spent on delivery in the period. This is the denominator that normalises debt growth against output, so use the same definition of delivery hours every time.

4. 4

   The calculation

   Subtract remediated from added to get net debt, divide by development effort, and multiply by 100. A positive percentage means debt grew relative to the work, a negative one means the team paid down faster than it borrowed.

Read the result against a target band rather than as a pass or fail. A rate near zero means debt is broadly holding steady relative to output. A persistently positive rate means each unit of delivery is leaving the codebase a little worse, which compounds into the slower cycle time and reduced deployment frequency that teams feel long before they name the cause. Plotting the rate period over period is what surfaces the trajectory.

A metric tree decomposes the accumulation rate into the three quantities that produce it, debt added, debt remediated, and development effort, and traces each back to the practices that move it. Because the rate is a ratio, the tree has to explain both the numerator and the denominator, since the percentage can shift even when raw debt holds steady.

The numerator splits into the familiar pair of added and remediated debt, each with its own drivers. The denominator, development effort, is the part teams forget to model. A falling rate can come from genuinely better practices, or simply from a busier delivery quarter that inflated the denominator. The tree keeps these apart so you do not mistake a temporary surge in output for a real improvement in discipline.

This structure makes the rate diagnosable. If it rises, the tree shows whether the cause is more debt added, less debt cleared, or a quieter delivery period shrinking the denominator. Each of those points to a different owner and a different response, and only the first two are actually about codebase health.

Because the rate is normalised, it travels better between teams than raw accumulation, but it still varies with codebase maturity and the deliberate trade-offs a team is making. Read it as a band and watch the direction across several periods rather than fixating on a single reading.

The strongest signal is not the level but the slope. A rate that climbs steadily across three quarters is a problem even if it is still inside an acceptable band, because the compounding will carry it out of that band soon enough. A high but falling rate, by contrast, is a team that has recognised the issue and is actively working it down.

Lowering the rate means moving the same levers as raw accumulation, slowing debt added and raising debt cleared, but with one extra caution: do not chase the number by inflating the denominator. Real improvement comes from the numerator. Pushing more hours into delivery to dilute the rate just hides the problem.

The metric tree approach to lowering the rate starts by checking whether the numerator or the denominator is moving. If net debt is climbing, the work sits in the quality gate and the remediation allocation, owned by engineering leads. If the rate only moved because delivery hours swung, the right response may be to do nothing at all and wait for the denominator to settle.

KPI Tree lets you model this by connecting each branch of the rate tree to the team and the practice behind it. Engineering leads own the gate that limits new debt. Platform owns the upgrade cadence. Delivery leads own both the protected remediation time and the delivery-hours denominator. With RACI ownership on every node, a rising rate is investigated by the person accountable for the branch that actually moved, not debated in the abstract. When the rate shifts, that owner is pushed the change and can confirm whether it reflects real decay or just a swing in output.

1. 1

   Ignoring the denominator

   Treating the rate as if only debt moves it misses that development effort sits underneath. A change in delivery hours shifts the percentage on its own, so always read the numerator and denominator together.

2. 2

   Inconsistent effort measurement

   If development hours are counted generously one quarter and tightly the next, the rate swings for reasons that have nothing to do with the codebase. Fix one definition of delivery effort and keep it.

3. 3

   Comparing rates across very different codebases

   Normalisation helps, but a greenfield service and a legacy monolith still behave differently. Compare a team mostly against its own history rather than ranking unlike codebases on a single number.

4. 4

   Optimising the rate by adding delivery

   Throwing more hours at features to dilute the percentage lowers the rate without improving anything. The codebase is no better, the number just looks calmer.

5. 5

   Reading a single period in isolation

   One quarter is noisy. The rate is built to be read as a trend, so a single reading rarely justifies a major decision. Look at the slope across several periods before acting.