A client once asked us to spend a full sprint refactoring a piece of code that, on inspection, was genuinely ugly, poorly named, and had zero test coverage. It also handled a feature used by about a dozen internal admin users, changed roughly twice a year, and had not caused a single production incident in eighteen months. Meanwhile, their checkout flow, which processed real customer payments, had a subtle race condition nobody had prioritized fixing because the code, on the surface, looked fine. We redirected that sprint. This is the core thing most technical debt conversations get wrong: they treat "ugly code" and "risky code" as the same problem, and they are often not.

The framework we actually use

We stopped asking "is this code bad" and started asking two separate questions for anything a team flags as technical debt: how often does this code change, and how bad is the outcome if it breaks. Plotting debt against those two axes, rather than against how uncomfortable the code makes a senior engineer feel to look at, changes the priority order dramatically.

Changes often, breaks badly — fix this now, it's actively compounding risk every sprint you leave it
Changes often, breaks mildly — worth fixing opportunistically, when you're already in that code for a feature, not as a dedicated project
Changes rarely, breaks badly — write tests around it and leave the implementation alone; the risk is real but a rewrite risk introducing new bugs into something that currently, if ugly, works correctly
Changes rarely, breaks mildly — genuinely fine to ignore, possibly forever, and that's not a failure of discipline, it's correct prioritization

That admin feature the client wanted refactored was squarely in the bottom-right box: rarely touched, low blast radius if something went slightly wrong. The checkout race condition was top-left: payments code changes with some regularity as the business adds payment methods, and a race condition there has genuinely bad outcomes, up to and including the double-charge scenario that keeps backend engineers up at night. Ugly code in the bottom-right box is not a priority, no matter how much it bothers the engineer who has to glance at it twice a year.

The trap: debt that feels urgent because it's visible, not because it's risky

Code that a senior engineer sees regularly and finds embarrassing generates a specific kind of pressure to fix it that has nothing to do with actual business risk. We've sat in enough planning meetings to recognize the pattern: someone opens a file they haven't touched in months, winces at code they wrote in a hurry two years ago, and proposes a refactor with more emotional urgency than the actual risk profile justifies. That reaction is worth noticing and separating from the decision. "This embarrasses me" and "this is going to cause an incident" are different signals, and only one of them should drive sprint planning.

Debt you take on deliberately is different from debt you accumulate by accident

Not all technical debt is a mistake. We regularly ship a known-imperfect solution deliberately, to hit a launch date or validate a feature before investing in a more robust version, and that's a legitimate engineering tradeoff as long as it's made consciously and tracked, not silently absorbed into "how things are." The failure mode isn't taking on debt, it's taking on debt without writing down that you did, so six months later nobody remembers it was a deliberate shortcut versus an oversight, and it never gets reprioritized because it's invisible.

// A comment convention we now enforce for deliberate shortcuts
// DEBT(2026-03): Skipping input validation here for launch deadline.
// Risk: malformed CSV uploads could corrupt the batch import.
// Revisit: before opening this feature to external customers.
function importBatch(csvRows) {
  return csvRows.map(parseRowWithoutValidation);
}

That tag gets picked up by a script that surfaces every DEBT comment in the codebase during quarterly planning, so deliberate shortcuts actually resurface for a real reprioritization decision instead of quietly becoming permanent by default, which is what happens to almost every shortcut nobody tracks.

What this actually changes about planning

Once you separate "ugly" from "risky" and separate "accidental" from "deliberate," technical debt stops being a vague, guilt-driven backlog category that never gets prioritized against real feature work, because nobody can articulate why any specific item matters more than the next one. It becomes something you can actually rank against the same criteria you'd use for a feature: what's the cost of leaving it, what's the cost of fixing it, and how confident are you in either number. Most technical debt doesn't need a sprint. Some of it needs one urgently. The skill is telling the two apart before a customer finds out for you.