Most engineering teams get one reliable opening each year to fund cleanup work: the stretch of Q4 when feature roadmaps thin out, change freezes approach, and next year’s budget gets written. Proposals to “pay down tech debt” usually fail in that room because they arrive as a feeling. Leadership hears that the code is messy and the team would like time to fix it, which sounds like a request to pause delivery for taste.

A cleanup sprint gets approved when it reads as an investment with a defined scope, a measurable target, and a limited downside. This guide walks through building that case.

Why the argument usually fails

Engineers talk about debt in terms of structure: coupling, outdated frameworks, missing tests. Executives hear it in terms of delivery and risk, if they hear it at all. The translation has to happen on the engineering side.

The cost is real, even if exact numbers are slippery. Stripe’s report The Developer Coefficient, a survey of executives and developers in six countries, put the average estimate at 17.3 hours of a 41.1-hour developer week spent on maintenance, which it split into 13.5 hours of technical debt and 3.8 hours of bad code. Those are self-reported estimates from an older survey, so treat them as a direction and not a benchmark. The more convincing numbers are your own.

Step 1: Build a debt inventory with costs attached

Start with a list, but a list sorted by pain, not by how offensive the code looks. For each candidate item, capture:

  • What it is, in one sentence a non-engineer can follow.
  • Who it affects, such as one team, several teams, or customers.
  • What it costs now, in a unit leadership already tracks: incidents, hours of rework, slow builds, delayed releases, or support tickets.
  • What it blocks, such as a feature on the roadmap, a security upgrade, or a platform migration.
  • The fix, scoped small enough to finish within a single sprint.

Pull the evidence from systems you already have. Incident postmortems show which components cause outages. Your ticket tracker shows which modules attract repeated bug fixes. Version control history shows files that change constantly and carry the most defects. A short survey of engineers asking where they lose the most time often surfaces items the dashboards miss.

Drop anything you cannot attach a cost or a blocker to. It may be real debt, but it is not a Q4 candidate.

Step 2: Choose measures leadership already respects

Frame the sprint around outcomes, and pick two or three measures before you start. DORA’s four keys are a reasonable vocabulary because many leaders recognize them: change lead time, deployment frequency, failed deployment recovery time, and change fail rate. DORA’s own guidance applies here. Use them at the level of a single application or service rather than comparing teams, and avoid turning them into targets that people will game.

Practical examples of measurable targets:

  • A flaky test suite that causes frequent failed pipeline runs: track pipeline failure rate and re-run counts.
  • A slow build: track median build and test duration.
  • A fragile service behind repeated incidents: track incident count and recovery time for that service.
  • An end-of-life dependency: track the number of services on the old version, and the date it leaves vendor support.

Capture the baseline before the sprint begins. A cleanup claim without a before number is an anecdote.

Step 3: Scope it so it can actually finish

Sprints that fail usually tried to do too much. Apply a few rules:

Pick items that finish. Favor changes a team can complete and ship, not the first step of a multi-quarter rewrite. If the real fix is large, carve out a slice that produces a standalone benefit, such as one service migrated or one subsystem under test.

Prefer debt on the path of upcoming work. Cleanup that unblocks a planned 2027 feature is easier to defend than cleanup that benefits nothing in the roadmap.

Include a security and maintenance bucket. Dependency upgrades, expiring certificates, and end-of-life runtimes have external deadlines, which makes them the easiest to approve. Put them first.

Hold some capacity back. Production incidents will still happen. Planning the sprint at full capacity guarantees you will cut scope in the middle of it.

Define done. Each item needs an observable finish line: the old module deleted, the pipeline passing consistently, the dependency upgraded in all services. Partial cleanup that leaves two systems side by side is often worse than none.

Step 4: Work around the freeze

A year-end freeze can help or hurt. If production deploys are restricted, you may be limited to changes that are safe to ship or that can wait behind a feature flag. Plan accordingly:

  • Prioritize work that reduces risk without changing behavior: test coverage, tooling, build speed, observability, and documentation.
  • Stage riskier refactors behind flags so they can merge and sit dormant until the freeze lifts.
  • Confirm with the release owner exactly what the freeze allows. Rules differ widely between organizations, and assuming wrongly wastes the sprint.
  • Use quiet weeks for work that is awkward at other times, such as dependency upgrades across many repositories, since fewer concurrent feature changes means fewer merge conflicts.

For decisions about which refactors earn their cost, our guide on when to refactor offers a useful filter, and the unit testing strategy piece helps if the sprint is about building a safety net first.

Step 5: Write the one-page proposal

Leadership approves clear, short documents. Structure yours as:

  1. The problem, stated as a cost: what this debt is costing in incidents, delays, or risk.
  2. The scope: the three to five items selected, with owners.
  3. The measures: the baseline and the target for each.
  4. The cost: engineer capacity and what it displaces on the roadmap, named honestly.
  5. The risk plan: how work is shipped safely during the freeze, and what gets cut first if capacity shrinks.
  6. The report-back: when and how you will show results.

Naming what the sprint displaces matters. Leaders trust requests that acknowledge costs more than requests that pretend the work is free.

After approval: prove it

The sprint is also your credibility for next year. Report the before and after numbers on the measures you chose, including the ones that did not move. Say plainly what was finished, what slipped, and what you learned. A team that delivers a modest, measured result is far more likely to get a second cleanup approved than one that promised a transformation.

Then fold the practice into normal work. Reserve a standing slice of capacity for maintenance in each planning cycle, keep the debt inventory live, and add new entries when incidents reveal them. One well-run sprint opens a conversation, but a regular, visible allocation is what keeps the codebase from needing a rescue every Q4.