Technical Debt Prioritisation Tool

Ward Cunningham coined the debt metaphor in his 1992 OOPSLA experience report on the WyCash portfolio system, and the useful half of it is the interest. Shipping code you know is not quite right is borrowing. Every change you make on top of it afterwards pays interest. Some debt charges a fortune every week. Some charges nothing at all, because nobody ever touches that part of the system.

So the first question for any item is "what does this cost us, and how often?". A 3,000-line file that nobody has opened since 2021 is ugly and cheap. A slightly awkward module that four people change every sprint is expensive.

I score every item on three things, then make a decision rather than a ranking:

The tool above sorts everything into these four. They are the same four I use with teams, and the discipline is in keeping the first bucket small.

Neither, if you do it properly. The mistake I see most is treating debt as a separate project that has to compete with features for a slot on the roadmap. It always loses that fight, because a feature has a customer attached and a refactor has an engineer attached.

The better move is to tie debt to the roadmap. If next quarter is SSO and the auth code is a mess, cleaning up auth is part of shipping SSO, and it goes in the estimate. Paying down debt in the code you are about to change is the cheapest it will ever be. Paying it down in code nobody is touching is the most expensive, for the least return.

For whatever is left over, protect a fixed slice of capacity rather than negotiating every item. Teams disagree on the right size of that slice, and it should move with how much the debt is actually costing you. What matters is that it is agreed once and defended, instead of relitigated every sprint.

And when you do need to ask a non-technical founder or board for the time, talk about delivery speed, incidents and risk. A board will not follow an argument about cyclomatic complexity. They will follow the fact that the last three features each slipped by two weeks for the same reason. The tool writes you that paragraph.

Martin Fowler's technical debt quadrant, from 2009, splits debt by whether it was deliberate or inadvertent and whether it was prudent or reckless. Shipping something you know will not scale, with a plan to fix it after launch, is deliberate and prudent. A team that never learnt to write tests is inadvertent and reckless. It is a useful lens for retros, because the fix for reckless debt is usually in how the team works rather than in the code.

For prioritisation, the kind matters less than where it lives. The categories the tool uses are the ones that change the decision:

It works from what you type, not from your code. It has no idea whether the "unmaintainable billing module" is genuinely dangerous or just unfamiliar to the person describing it. Teams regularly misjudge their own debt in both directions: something everyone complains about turns out to be fine, and something nobody mentions turns out to be the real problem. A description cannot surface that. Reading the codebase can.

Effort is a size, not an estimate, and it will say "unknown" when your description does not give it enough to go on. It will never give you hours, days, story points or a cost, because any number produced from three lines of text would be made up.

It is also a language model, so read the decisions as a well-argued starting point for your planning meeting and not as a verdict. The questions it lists at the top of the result are the places it had to guess. Answer those first.

Run the tool and nothing you paste is stored. Submit the form to unlock more runs or download the plan, and what you typed comes to us with your address, which is what the tick box on that form says. Either way, leave out secrets, keys, credentials and client names. Describe the problem, not the password.