Every team that maintains custom software eventually faces the same argument. Engineers say the code is getting harder to change. The business says the roadmap cannot wait. Without a rule, the roadmap wins every sprint, until delivery slows down so much that a large clean-up becomes unavoidable and far more expensive.
This article gives technology leaders a practical alternative: a fixed share of capacity for technical debt, a small set of signals to check that it works, and a way to explain it to a finance director. For the background on why the debt builds up, read the hidden cost of technical debt. Here we focus on the budget itself.
Treat it as a budget line, not a negotiation
If debt work has to be argued for in each planning meeting, it is the first thing to be cut. A standing share removes the argument. The team knows how much capacity is reserved, the business knows what it is paying for, and both can judge the result later.
The principle is the same one finance already uses for maintenance of physical assets: a part of the running cost is set aside so that the asset keeps working. Software that is in use needs the same.
How to choose the share
There is no universal percentage, and we do not claim one. Published rules of thumb vary widely, and the right number depends on your system's age, your release pace and how much debt already exists. A sound way to decide:
- Measure what you spend now. Look at the last three or four sprints. How much time went to bug fixing, workarounds and tidying before feature work? Most teams find it is already a significant share, only unplanned and invisible.
- Pick a starting share and a period. Choose a fixed fraction of each sprint, for example for the next six sprints, and write it down. A team with heavy existing debt will start higher than one with a young codebase.
- Count it as capacity, not as overtime. Plan features on the remaining capacity. If the share comes out of evenings, it is not a budget.
- Review at the end of the period using the signals below, then raise it, lower it or keep it.
Three signals that the debt is slowing you down
You do not need a large metrics programme. Three numbers, taken from the tools you already have, are enough.
- Lead time for a small change. How many days pass from starting a typical small change to having it live? A rising trend on similar work is the clearest sign of friction.
- Rework. How often does finished work come back as a defect or a follow-up fix? Count items reopened or fixed within a few weeks of release.
- Unplanned work. What share of the sprint is taken by urgent issues that were not planned? When it grows, the team is paying interest on old shortcuts.
Record the three numbers before you start and again at each review. You are looking for direction, not precision. If they improve while the share is spent, the budget is working. If they do not, either the money goes to the wrong debt or the problem lies elsewhere, such as unclear requirements.
Spend the share where it pays back
Not every untidy corner deserves attention. Rank candidates by one question: does this block or slow work that is already planned? Good targets are:
- modules that nearly every upcoming feature has to touch
- areas that cause repeated incidents or support requests
- missing automated tests around critical paths, which make every change risky
- outdated components that no longer receive security fixes
Leave aside code that is ugly but stable and rarely touched. Rewriting it feels satisfying and returns little. Where a larger piece of work is needed, split it into steps that can each be released on their own, as described in our guide to modernising legacy systems.
How to explain it to finance
Finance does not need to understand the code. It needs to understand what the money buys and how you will show it. A short version that tends to hold up:
"We reserve a fixed share of engineering capacity to keep the system cheap to change. It is a maintenance budget, like servicing equipment. We track three numbers - lead time for small changes, rework and unplanned work - and review them every quarter. If they do not improve, we change how we spend the share or reduce it."
Add three supporting points:
- It is not extra cost. The share is taken from existing capacity, so the headcount budget does not change. What changes is what the capacity is used for.
- It limits a larger future bill. The alternative is a rewrite or a freeze on features later. Our business case for custom software shows how to compare such options with costs and risks side by side.
- It has an exit. The share is agreed for a fixed period and reviewed against evidence, so it is not an open-ended commitment.
Worked example (invented numbers, for illustration only). A team of eight plans six sprints. Looking back, it finds that about one fifth of recent sprint time went to unplanned fixes. The leader proposes reserving a fixed share for debt for the next six sprints, ranked by what blocks planned features. Before the start, the typical small change takes 9 days to go live and 1 in 6 releases needs a follow-up fix. After six sprints the review finds 7 days and 1 in 10. The leader presents these figures to finance, with the note that two sprints were disrupted by an incident and the trend may be partly due to that, and proposes to keep the share for another period.
Common mistakes
- Setting a share without measuring the starting point, so no result can be shown later.
- Letting the share shrink quietly when a deadline approaches, which turns the budget back into a negotiation.
- Spending it on personal preferences instead of debt that blocks planned work.
- Reporting code metrics that finance cannot connect to money or risk.
- Treating the share as permanent without review.
Where to start this week
Take the last four sprints and estimate how much time went to bug fixes, workarounds and unplanned work. Write down today's lead time for a small change. Then propose a share and a review date to your finance partner, using the three-sentence explanation above. A short, evidence-based proposal is far easier to approve than a general plea to clean up the code.
Sources
- Your own sprint, ticket and release records, collected as described; all figures in the worked example are invented for illustration.
- Our related articles linked above.