Why the Cleanup Sprint Always Loses - by Lamis

The Structural Read

SubscribeSign in

Why the Cleanup Sprint Always Loses<br>A four-field template for technical-debt proposals that get approved

Lamis<br>Jul 11, 2026

Share

There are two ways to describe technical debt to the people who own the roadmap.<br>The first way: “The payment module is a mess.” This sentence usually loses.<br>The second way: “Every feature that touches the payment module costs about two extra days, and we ship six of those each quarter.” This sentence usually wins.<br>The first sentence is an adjective. The second is a price. A roadmap can compare a price with other prices. An adjective can only be believed or doubted, and doubting is cheaper.<br>Debt that has no price cannot be paid. Nobody can approve paying off a number that does not exist.<br>Before proposing any repayment, write the debt as an item with four fields:<br>Construct What it is, exactly, and where. Specific enough to point at.

Interest What it costs per week or per quarter, in numbers the organization already tracks.

Principal What it would cost to fix.

Trigger What upcoming work will make the interest grow.

Filled in, it looks like this:<br>Construct The payment logic is duplicated across three services, so every change must be made three times.

Interest About two extra days for every feature that touches the payment logic. We ship six of those per quarter, so roughly twelve days each quarter. Four of the last ten incidents happened because the three copies no longer matched.

Principal Around three weeks to consolidate the logic into one service.

Trigger The Q4 checkout redesign will touch the payment logic in every sprint.

An item written this way answers the only question that actually matters to the people deciding: is this loan worth keeping? Twelve days per quarter, against a three-week repair, with the interest about to grow. The decision almost makes itself. And the format works in the other direction too. A module full of ugly code, with no changes planned, produces an empty interest field. An empty interest field is also an answer: the item can be closed on purpose. The debt exists, we accept it, and it costs us nothing for now. The format wins the arguments that deserve to be won, and it quietly ends the ones that were never worth having.<br>The framing comes from the SEI’s work on technical debt, the book Managing Technical Debt by Kruchten, Nord, and Ozkaya, and their definition is the part I use most. Debt is not the same as ugly code. Debt is a construct that was convenient once and now makes future change more expensive. A cost that repeats, attached to a specific place. The metaphor itself goes back to Ward Cunningham, who invented it to explain rework to finance people. It was born as a pricing device. The industry kept the word and dropped the pricing.<br>Three habits keep the template honest:<br>The first is to price the interest in numbers the organization already tracks: lead time, change failure rate, incident minutes, the multiplier on estimates. A rough number with an honest error range wins against a confident adjective, because a rough number can be argued with, and being arguable is what makes something approvable. When you cannot fill the interest field, hold the item back. Not because the code is fine, but because what you have at that point is a complaint about taste.

The second is to attach the principal to work that is already moving. Asking for a separate cleanup sprint turns the repair into a favor. The stronger structure puts the payment inside the features that already pass through the indebted area. Kent Beck compressed this into one line: “make the change easy (warning: this may be hard), then make the easy change.” The estimate for the feature includes making it easy. That is not padding. It is the true price of building in that part of the system, and quoting true prices does not require anyone’s permission.

The third is to let some debt stay. Prioritize by interest against the roadmap, not by ugliness, which means some of the worst code you know keeps existing, and that is the system working correctly. The same honesty runs in the other direction: a repair that cannot name the future change it will make cheaper is not repayment. It is renovation, and it should compete for time as renovation.

Three signs that the pricing has gone missing:<br>A refactoring ticket that gets recreated every quarter and never scheduled. The problem is usually not that nobody cares. The problem is that nobody priced it. The fix is a number, not a louder adjective.

Estimates in one part of the system that keep growing while the team slowly stops explaining why. That is interest being paid without being recorded. Write it down.

A debt register where every item is marked critical. That is a complaint list in a different shape. Real ranking means openly deciding that some debt stays.

One more reason this stopped being optional. AI now produces code faster than anyone can...