Sprint Planning with Tech Debt
How to consistently allocate capacity for debt reduction without sacrificing feature delivery or losing stakeholder trust.
The Capacity Question
The #1 Question: "How Much Capacity Should Go to Debt?"
Every tech lead asks this question eventually. The answer is not a guess - it comes from years of industry data across thousands of engineering teams. Get this number right, and you build a sustainable system. Get it wrong in either direction, and you lose.
Debt accumulates faster than you fix it. You are falling behind every sprint. Within a year, velocity drops noticeably and developers start leaving.
The sweet spot. Debt stays manageable, features ship on time, and the codebase improves steadily. This is where the best engineering teams operate.
Features stall and stakeholders lose patience. Product managers start asking why nothing is shipping. You may be solving the right problem the wrong way.
Critical debt - security vulnerabilities, outage-causing bugs, compliance risks - gets whatever it takes. These are not negotiable and override normal allocation.
The 20% Rule
Allocate 20% of sprint capacity to debt. Treat it as non-negotiable, like keeping the lights on. You do not negotiate whether to pay the electric bill, and you do not negotiate whether to maintain the codebase. The 20% is the cost of sustainable software development.
Debt Stories vs Feature Stories
The biggest mistake teams make with debt work is writing vague stories that cannot be estimated, prioritized, or demonstrated. A well-written debt story looks exactly like a feature story - with a clear actor, action, and measurable outcome.
The Debt Story Template
"As [team/system], we need to [remediation action] so that [measurable business outcome]"
BAD: Vague Debt Story
"Refactor the payment module"
- No measurable outcome
- Cannot be estimated accurately
- No way to know when it is done
- Impossible to demo in sprint review
GOOD: Measurable Debt Story
"Reduce payment module complexity from cyclomatic 47 to under 20, eliminating the #1 source of deploy failures"
- Measurable target (cyclomatic complexity)
- Business impact (deploy failures)
- Clear definition of done
- Can show before/after metrics in review
Include Acceptance Criteria
Every debt story needs acceptance criteria tied to metrics. "Code is cleaner" is not an acceptance criterion. "Cyclomatic complexity drops below 20" is. "Tests pass faster" is vague. "Test suite runs in under 90 seconds" is verifiable.
Examples: Build time under X minutes, error rate below Y%, test coverage above Z%, zero critical SonarQube findings in module
Point Debt Stories the Same Way
Point debt stories using the same estimation process as feature stories. If your team uses story points, point them. If you use t-shirt sizing, size them. Unpointed work is invisible work, and invisible work does not get credit or protection when capacity gets tight.
Why it matters: Velocity metrics only reflect pointed work. If debt stories are unpointed, your velocity looks artificially low when you invest in debt reduction.
The Sprint Planning Ritual
Follow this step-by-step process every sprint planning session. The order matters - debt allocation happens before feature selection, not after. This prevents the "we will do debt work if there is time left" trap that ensures debt work never happens.
Review Capacity
Calculate total team availability minus ceremonies, PTO, and on-call duties. This is your real capacity for the sprint - not the theoretical maximum, but what you can actually commit to delivering. Be honest here. Overcommitting is worse than undercommitting.
Calculate Debt Allocation
Multiply your real capacity by 0.2. That is your debt budget for this sprint. If you have 50 story points of capacity, 10 points go to debt work. Write this number down and protect it. This is not a suggestion - it is a commitment.
Pull from Prioritized Debt Backlog
Select debt stories that fit within your debt allocation from the prioritized debt backlog. Pull the highest-priority items first. If a debt story is too large for the allocation, break it down into smaller increments that deliver value independently.
Pull Feature Stories with Remaining Capacity
Now fill the remaining 80% with feature stories from the product backlog. This order is deliberate. Debt gets allocated first because feature pressure always wins if debt competes for leftover capacity. The 80% is still a significant amount of feature work.
Check for Dependencies
Look for dependencies between debt and feature stories. Sometimes debt work unlocks blocked features - call this out explicitly because it strengthens the case for debt investment. Sometimes feature work conflicts with planned debt work - resolve this before committing.
Team Commitment
Ask the team: "Does this feel achievable?" If the answer is uncertain, remove the lowest-priority feature story - never the debt stories. The team needs to own this plan. A commitment they believe in is worth more than an ambitious plan they doubt.
Communicating to Product
The conversation with product managers about debt allocation is one of the most important conversations a tech lead has. Get it right, and product becomes your ally. Get it wrong, and every sprint planning becomes a fight.
Never Apologize for Debt Allocation
Phrases like "I know this takes away from features, but..." undermine your position before you start. The 20% debt allocation is not a favor you are asking for. It is a professional engineering practice, like testing or code review. You do not apologize for writing tests. Do not apologize for maintaining the codebase.
Frame It as Investment
"This 20% makes the other 80% go faster." That is the core message. Teams that invest in debt reduction consistently show higher velocity over time. You are not taking capacity away from features - you are investing in the ability to ship features faster in the future.
Show the Velocity Trend
Teams that invest in debt reduction see velocity increases of 15-30% over six months. Pull your own team's data. Show the trend line. If you have not been investing in debt, show the declining velocity and explain what is causing it. The numbers tell the story better than words.
The Building Maintenance Analogy
Compare it to maintenance on a building. Nobody asks "can we skip the HVAC maintenance this month to fit more tenants?" The building does not work without maintenance. The software does not work without debt reduction. Deferred maintenance becomes emergency repairs that cost 5-10x more.
Have Data Ready
Before the conversation, gather concrete data points that connect debt to business outcomes. Do not walk in with opinions - walk in with numbers.
Incident frequency and mean time to resolve over the past quarter
Deploy time trend and how it has changed month over month
Ramp-up time for new hires and how debt slows onboarding
Sprint Review: Showing Debt Progress
Debt work that nobody sees is debt work that gets cut. Make your debt progress visible in every sprint review, with the same energy and polish you give to feature demos.
Demo Debt Items in Sprint Review
Include debt items in your sprint review demo alongside features. Show the change, explain the impact, and connect it to something stakeholders care about. "We reduced build time from 12 minutes to 4 minutes" is a demo-worthy accomplishment.
Show Before/After Metrics
Never say "we refactored X." Instead, show the numbers: complexity went from 47 to 18, test coverage went from 34% to 82%, deploy failures in this module dropped from 3 per week to zero. Metrics make the invisible visible and the abstract concrete.
Celebrate Debt Wins
Celebrate debt wins the same as feature wins. If your team high-fives when a feature ships, high-five when a critical debt item is resolved. Culture follows what you celebrate. If debt work is invisible and uncelebrated, people will avoid it.
Track Cumulative Progress
Track cumulative debt reduction quarter over quarter. Individual sprints show small wins, but the quarterly trend tells the real story. A chart showing steady debt reduction over six months is a powerful argument for continued investment.
Common Mistakes
These are the pitfalls that derail even well-intentioned debt reduction programs. Every one of them sounds reasonable in the moment, and every one of them leads to the same outcome: debt work quietly disappears from your sprints.
Treating Debt Allocation as "Optional When Busy"
The team is always busy. There is never a calm sprint where debt work feels easy to justify. If your 20% allocation flexes based on feature pressure, it will be 0% within two sprints. Make it non-negotiable or accept that it will not happen.
Only Doing Debt When There Is "Leftover" Capacity
There is never leftover capacity. Feature backlogs are infinite. If debt work waits for spare time, it waits forever. That is why debt allocation happens before feature selection - not after. The order of operations in sprint planning is not a suggestion.
Not Pointing Debt Stories
Unpointed work is invisible work. If debt stories do not have story points, they do not show up in velocity, they cannot be compared to feature work, and they get deprioritized because there is no visible cost to removing them. Point them the same as feature stories.
Doing All Debt at Once (Big Bang Refactoring)
The impulse to "just rewrite the whole thing" is strong and almost always wrong. Big bang refactoring creates massive risk, blocks feature delivery for weeks or months, and usually fails. Steady, incremental debt reduction in every sprint is safer, more sustainable, and produces better outcomes.
Not Communicating Debt Progress to Stakeholders
If stakeholders do not see the results of debt work, they conclude that nothing happened. Show before/after metrics in sprint review, track cumulative progress quarterly, and connect every debt win to a business outcome. Silence about debt progress is interpreted as wasted effort.
Frequently Asked Questions
Start with data, not arguments. Show incident frequency, deploy failure rates, and velocity trends. If the data does not convince them, try a time-boxed experiment: run two sprints at 20% debt allocation and measure the results. Most product managers will agree to an experiment even if they resist a permanent policy change. Once they see the velocity improvement, the conversation changes from "why are we doing this" to "should we do more."
Use the same estimation process as feature stories. If you do planning poker, include debt stories in the poker session. Break large debt items into smaller pieces that can be completed in a single sprint. Add a spike story first if the scope is genuinely unknown - a 2-point spike to investigate and write the real stories is better than guessing at an 8-point estimate. Track your actual vs. estimated for debt stories and use that data to improve future estimates.
Absolutely. Every debt story needs acceptance criteria tied to measurable outcomes. "Code is cleaner" is not an acceptance criterion. "Cyclomatic complexity of PaymentProcessor class is under 20, verified by SonarQube" is. "Tests are better" is vague. "Test coverage for the billing module exceeds 80%, and all boundary conditions have explicit test cases" is verifiable. Without clear acceptance criteria, debt stories become open-ended work that never finishes.
Critical bugs take priority - that is not negotiable. But track the disruption explicitly. Log that the debt stories were deferred because of a critical bug, and carry them forward to the next sprint with increased priority. If critical bugs frequently disrupt debt work, that is itself a sign of accumulated debt. Use the disruption data to make the case for more aggressive debt investment: "We cannot maintain our 20% allocation because the other 80% keeps catching fire."
Break it into independently deliverable increments. Each increment should leave the system in a better state than before, even if the full remediation is not complete. Use an epic to track the overall effort and individual stories for each sprint's contribution. Avoid stories that say "continue refactoring X" - each story should have its own acceptance criteria and deliver specific, demonstrable value. If you cannot break a debt item into sprint-sized pieces, consider whether the approach is right.
Debt sprints - dedicating an entire sprint to nothing but debt work - sound appealing but fail in practice. They create a feast-or-famine cycle where debt accumulates for weeks, gets partially addressed in one burst, then starts accumulating again. Stakeholders see a sprint with zero feature output and push back hard. The ongoing 20% allocation is more sustainable because it delivers consistent progress without creating political friction. The only exception is a critical debt emergency that genuinely requires all hands on deck.
Start Planning Smarter Sprints
Download the Sprint Planning Template to get started, or learn how to make the business case for debt reduction to your management team.