How to Prioritize Technical Debt - A Framework for What to Fix First
You cannot fix everything at once. The goal is not zero debt. It is fixing the debt that has the highest impact on your ability to ship, with the least effort. This framework helps you sort your debt backlog into a prioritized action plan.
Prioritization Matrix Builder
Add your debt items, score each on impact (1-5) and effort (1-5), and the matrix will classify them into four quadrants: Quick Wins (do first), Major Projects (plan carefully), Fill-ins (do when convenient), and Deprioritize (do not bother).
Add Debt Item
Priority Matrix
Quick Wins (High Impact, Low Effort)
- Add integration tests for auth flow
Major Projects (High Impact, High Effort)
- Migrate to TypeScript strict mode
Fill-ins (Low Impact, Low Effort)
- Refactor shared utils library
Deprioritize (Low Impact, High Effort)
Ranked by Priority
How to Score Impact
| Impact Question | Weight |
|---|---|
| Does it affect deployment frequency? | High - blocks the entire team |
| Does it cause production incidents? | High - customer-facing impact |
| Does it slow new engineer onboarding? | Medium - team scaling bottleneck |
| Does it block feature development? | High - direct revenue impact |
| Does it create security vulnerabilities? | Critical - compliance risk |
How to Score Effort
| Effort Factor | Scoring Guide |
|---|---|
| Lines of code affected | Under 500 = low, 500-2000 = medium, 2000+ = high |
| Number of services involved | 1 service = low, 2-3 = medium, 4+ = high |
| Test coverage of affected area | Above 70% = low risk, below 30% = high risk |
| Risk of regression | Isolated code = low, core business logic = high |
Risk-Weighted Prioritization
Beyond impact and effort, some debt items carry outsized risk. Security vulnerabilities in outdated dependencies, for instance, may have low business impact today but could cause catastrophic damage if exploited. Weight these higher regardless of the standard impact score.
Ticking Time Bombs: Always Prioritize These
- ! Known security vulnerabilities in production dependencies (CVEs)
- ! Single points of failure with no redundancy or failover
- ! Data loss risks from missing backup or recovery mechanisms
- ! Compliance violations that could result in regulatory penalties
- ! Authentication or authorization bypasses in legacy code
The Pain-Driven Approach
When formal prioritization feels too heavyweight, use a simpler method: fix what engineers complain about most. Run a quick survey asking the team to list the top 3 things in the codebase that slow them down or frustrate them. The items that appear most frequently are your highest-impact debt.
Sample Survey Questions
- 1. What area of the codebase do you dread working in the most?
- 2. What takes you the longest time but should be simple?
- 3. If you could rewrite one component from scratch, which would it be?
- 4. What causes the most bugs or incidents?
- 5. What would make the biggest difference to your daily productivity?
Sprint Planning Integration
Debt items should be treated as first-class work items in sprint planning. Here is the recommended ticket format:
| Field | Example |
|---|---|
| Title | Eliminate circular dependency in payment-service |
| Type | Technical Debt |
| Impact Score | 4/5 - blocks 3 feature stories this quarter |
| Effort Score | 2/5 - estimated 3 days, single service, good test coverage |
| Business Impact | Payment processing latency exceeds SLA 12% of the time, risking $X in penalties |
| Expected Outcome | Reduce payment latency P99 from 2.3s to 0.8s, eliminate SLA violations |
| Success Metric | P99 latency below 1s for 30 consecutive days |