The most common question engineering managers ask about technical debt is not "what should we fix?" It is "how do we actually get time to fix it?" Every sprint planning session becomes the same negotiation: product wants features, engineering wants cleanup, and whoever makes the louder case that week wins. The result is inconsistency---months of zero debt work followed by a guilt-driven "tech debt sprint" that gets canceled when a deadline shifts.
TL;DR: Do not dedicate entire sprints to technical debt---integrate it into every sprint with a fixed 15-20% capacity budget. Select debt items using RIVER Framework scores, protect the budget like a sprint commitment, and track debt reduction velocity separately from feature velocity. Get stakeholder buy-in by framing debt as a productivity investment with measurable returns, not as engineering housekeeping.
The answer is not "tech debt sprints." It is making debt work a permanent, protected part of every sprint. This playbook covers the capacity math, the selection process, the stakeholder conversations, and what success looks like in practice.
Should you dedicate entire sprints to technical debt?
No. And this is a hill worth dying on.
"Tech debt sprints" feel productive in the moment. The team rallies, cleans up months of accumulated mess, and feels virtuous for a week or two. But this approach creates three serious problems that undermine long-term debt management.
Problem 1: They are politically expensive and easy to cancel. Every tech debt sprint requires a negotiation with product leadership. You are asking for two weeks of zero feature delivery, and the justification has to override whatever is on the roadmap. One urgent customer request, one shifted deadline, and the debt sprint gets bumped to "next quarter." In practice, teams that rely on dedicated debt sprints manage to schedule one or two per year at best.
Problem 2: They create a boom-bust cycle. The codebase accumulates mess for three to four months, gets a burst of cleanup, then immediately starts accumulating again. The codebase never reaches a sustainably healthy state because the cleanup cadence does not match the accumulation rate.
Problem 3: They signal to leadership that debt is optional. When debt work is a separate, cancellable event, it reinforces the belief that debt is a nice-to-have. Features are the real work; debt is what engineers do when there is nothing more important. This framing makes it impossible to build sustained investment.
The alternative: a consistent, protected budget in every sprint. Not a separate event. Not a negotiation. A fixed allocation that runs on autopilot, sprint after sprint.
How much sprint capacity should go to technical debt?
The guideline is 15-20% of sprint capacity, treated as a non-negotiable budget. In our experience, teams that follow this consistently maintain or improve their feature delivery velocity over time.
The math
For a 6-person team running 2-week sprints with an average velocity of 60 story points:
- 20% debt budget = 12 story points per sprint dedicated to debt reduction
- Remaining capacity = 48 story points for feature work
- Annual debt investment = approximately 312 story points (26 sprints x 12 points)
That annual investment is enough to resolve dozens of meaningful debt items, remove hundreds of stale feature flags, and measurably improve velocity---all without ever asking product to sacrifice a full sprint.
When to break the rule
The 15-20% range is a default, not a mandate. Adjust based on your team's debt situation:
| Scenario | Budget | Duration |
|---|---|---|
| Debt is stable and manageable | 15-20% | Ongoing (default) |
| Debt is actively degrading velocity | 25-30% | One quarter, then reassess |
| Post-incident reveals systemic debt | 30-40% | 2-4 sprints, then step down |
| Critical launch approaching | 10% | Maximum 2 sprints, with explicit recovery plan |
| Debt backlog is small and shrinking | 10-15% | Until new debt items appear |
Never go below 10%. Technical debt compounds. Teams that regularly skip debt work for "just one more sprint" find themselves three quarters later with a backlog so large that no reasonable budget can address it.
How do you prioritize which technical debt to tackle in each sprint?
Having a budget is necessary but not sufficient. You also need a systematic way to decide which items fill it. This is where the RIVER Framework comes in---scoring each debt item across Risk, Impact, Velocity, Effort (inverted), and Reach on a 1-5 scale, producing a composite score out of 25.
Sprint-level selection rules
Rule 1: Always take the highest-scored items first. Pull from the top of the scored backlog. No cherry-picking items because they are more interesting or more familiar. The whole point of a scoring system is to remove subjective preferences from the selection process.
Rule 2: Prefer items completable within the sprint. A 12-point debt budget spent on one carry-over item delivers less value than three 4-point items that are each completed and shipped. Completed items build momentum, demonstrate progress, and actually reduce debt.
Rule 3: Break multi-sprint items into smaller pieces. If the highest-scored item is estimated at 20 points, it does not fit in a 12-point budget. Break it down. "Refactor the authentication module" becomes "extract token validation into a standalone function" (4 points), "remove deprecated OAuth 1.0 path" (3 points), and "add integration tests for refresh flow" (5 points). Each piece delivers value independently.
Rule 4: Assign specific owners. Every debt item must have a named engineer responsible for it. Unowned items do not get done---they sit in "In Progress" for two weeks and carry over indefinitely.
For feature flag debt specifically
When selecting flag-related debt items, prioritize the oldest flags first. A flag that has been permanently enabled for 180 days has accumulated more dead code, more conditional complexity, and more developer confusion than one that has been stable for 30 days. Older flags also tend to be simpler to remove because the feature they guarded has been thoroughly validated in production. Tools like FlagShark can identify stale flags automatically and generate cleanup pull requests, making flag removal one of the highest-ROI debt items you can select---low effort, high impact.
How do you get stakeholder buy-in for technical debt work?
The budget does not exist until leadership agrees to it. Here are five strategies that work.
Frame as investment, not cost. Do not say "we need 20% for tech debt." Say: "We invest 12 points per sprint in developer productivity improvements. We expect this to recover 8-10 hours per week of development time within one quarter---equivalent to adding a half-time engineer at zero hiring cost." The word "investment" implies a return. "Tech debt cleanup" implies cost with no return.
Show the cost of inaction. If velocity has declined, project the trend forward. "Our velocity dropped from 65 to 58 points per sprint over four quarters. At this rate, we deliver 15% fewer features next year with the same headcount." Declining velocity is something every product leader understands. For a detailed approach to building this case in dollar terms, see our ROI business case guide.
Make debt visible. Put debt items on the same board as features, not in a separate backlog nobody looks at. Demo completed debt items in sprint reviews: "This sprint, we removed 5 stale feature flags, eliminating 300 lines of dead code and simplifying three critical files."
Report separately. Maintain two velocity metrics: feature velocity and debt velocity. Report both every sprint. This proves the debt budget is effective and that feature delivery remains strong.
Use RIVER scores to demonstrate objectivity. Include the scored backlog when presenting the budget. Walk through examples. This removes the perception that engineers are lobbying for pet projects. A 21/25 item is more important than a 14/25 item, regardless of which engineer cares about which.
What does a successful debt reduction sprint look like?
Here is what a well-run sprint looks like for a 6-person team with a 20% debt budget.
Sprint planning
Total capacity: 60 points (48 features, 12 debt)
| Debt Item | RIVER Score | Estimate | Owner | Status |
|---|---|---|---|---|
| Remove 5 stale feature flags (90-180 days old) | 19/25 | 4 pts | Sarah | Selected |
| Fix flaky integration test in checkout flow | 18/25 | 5 pts | Marcus | Selected |
| Update deprecated payments API to v3 | 17/25 | 3 pts | Priya | Selected |
During the sprint
Debt items follow the same workflow as features: To Do, In Progress, In Review, Done. They appear in standups. Code reviews happen normally. There is nothing special about the process---debt work is work.
Sprint review
The team demos all completed work, including debt items:
- Stale flags removed: 5 flags permanently enabled for 90-180 days, eliminated ~300 lines of dead code across 8 files, simplified three high-density files that were frequent sources of merge conflicts.
- Flaky test fixed: Race condition in test setup (not application code) was causing 18% CI failure rate, now reduced to 3%.
- Deprecated API updated: 12 call sites migrated from payments API v1 to v3, resolving a security advisory.
Outcomes after one sprint
| Metric | Before Sprint | After Sprint | Change |
|---|---|---|---|
| Stale flags (90+ days) | 23 | 18 | -5 |
| Dead code lines (est.) | ~4,200 | ~3,900 | -300 |
| CI pass rate | 82% | 97% | +15% |
| Security advisories | 3 | 2 | -1 |
| Feature velocity | 49 pts | 48 pts | -1 pt (within variance) |
| Cleanup velocity ratio | 0.4 | 0.7 | +0.3 |
The critical observation: feature velocity was flat. The 12 points of debt work did not come at the expense of features---it came from the protected budget. And the returns (faster CI, less dead code, fewer security issues) compound over subsequent sprints. This is what sustainable debt management looks like. Not heroic sprints. Twelve points of deliberate, prioritized work, every single sprint.
Key Takeaways
- Never dedicate entire sprints to technical debt. Integrate debt work into every sprint with a fixed 15-20% capacity budget. Dedicated debt sprints are politically expensive, create boom-bust cycles, and signal to leadership that debt is optional.
- The math is straightforward. For a 6-person team at 60 points per sprint, a 20% budget means 12 points of debt work per sprint, compounding to over 300 points per year---enough to make a transformative difference.
- Select debt items using RIVER scores. Always pull from the top of the scored backlog, prefer items completable within the sprint, break large items into smaller pieces, and assign specific owners to every item.
- Frame debt work as a productivity investment, not a cost. "We invest 12 points per sprint and expect to recover X hours per week of velocity within one quarter" is a fundamentally different conversation than "we need time for tech debt."
- Track debt velocity separately from feature velocity. Two metrics, reported together, prove that the debt budget is effective and that feature delivery remains strong.
- Protect the budget. The debt budget is a sprint commitment, not a suggestion. When product requests exceed capacity, the debt allocation is the last thing cut, not the first. Never go below 10%.
People Also Ask
How do you handle technical debt in agile?
Use a fixed capacity budget---15-20% of every sprint dedicated to debt reduction. Do not create separate "tech debt sprints" or rely on slack time between features. Treat debt items the same as feature stories: scored, prioritized, assigned, tracked on the same board, and demoed in sprint reviews. Use a framework like RIVER to score items objectively, and fill the budget from the top of the scored backlog each sprint.
What percentage of time should developers spend on technical debt?
Allocate 15-20% of sprint capacity as a baseline---roughly one day per week per developer. Increase to 25-30% for a quarter if debt is actively degrading velocity, or spike to 30-40% for 2-4 sprints after a major incident. Decrease to 10-15% temporarily when the backlog is shrinking. Never go below 10%---the compounding nature of debt makes recovery exponentially harder the longer you defer it. Track debt metrics monthly to know which direction to adjust.
How do you track technical debt in Jira or Linear?
Score each debt item using a structured framework like RIVER and tag it with a "tech-debt" label. Place debt items on the same board as feature work so they are visible in standups, planning, and reviews. Track two velocity metrics separately: feature velocity and debt velocity. Report both to stakeholders each sprint. A simple custom field with the RIVER composite score (out of 25) provides an objective priority ranking that removes opinion from selection.
Should tech debt be in the product backlog?
Yes. Separating debt into a hidden backlog guarantees it gets ignored. When debt items are visible alongside features, they get discussed in planning and demoed in reviews. The key distinction is tracking: while items appear on the same board, track debt velocity as a separate metric so you can report on debt reduction progress independently. This gives leadership visibility into both feature delivery and debt management without requiring debt to win a head-to-head battle against features every sprint.