Technical Debt Prioritization | Impact-Effort Framework
Prioritize technical debt by impact, effort, and frequency. GitScrum tracks debt in backlogs with priority scoring to focus on what hurts productivity most.
7 min read
Not all technical debt is equal. Some debt blocks progress, some just slows things down, and some rarely matters. Good prioritization focuses effort where it creates the most value. This guide covers practical approaches to prioritizing tech debt.
Prioritization Matrix
| Impact | Effort | Priority |
|---|---|---|
| High | Low | Do First |
| High | High | Plan Carefully |
| Low | Low | Quick Wins |
| Low | High | Likely Never |
Categorizing Debt
Types of Tech Debt
TECHNICAL DEBT CATEGORIES
═════════════════════════
BY TYPE:
─────────────────────────────────────
Architecture debt:
├── System design problems
├── Scalability issues
├── Integration complexity
├── Hard to refactor
└── High impact, high effort
Code debt:
├── Poor code quality
├── Missing tests
├── Duplicated code
├── Unclear naming
└── Medium impact, varies effort
Infrastructure debt:
├── Outdated dependencies
├── Legacy tooling
├── Manual processes
├── Security concerns
└── Risk-based priority
Documentation debt:
├── Missing docs
├── Outdated information
├── Tribal knowledge
├── Onboarding pain
└── Often overlooked
BY IMPACT:
─────────────────────────────────────
Blocking:
├── Can't ship features
├── Major bugs
├── Security vulnerabilities
└── Must address now
Slowing:
├── Takes longer to develop
├── Frequent bugs in area
├── Hard to understand
└── Address strategically
Annoying:
├── Developer frustration
├── Minor inefficiency
├── Cosmetic issues
└── Low priority
Assessment Framework
Evaluating Debt
DEBT ASSESSMENT
═══════════════
EVALUATION CRITERIA:
─────────────────────────────────────
For each debt item, score:
Impact (1-5):
├── 5: Blocks major features
├── 4: Significant slowdown
├── 3: Noticeable friction
├── 2: Minor inconvenience
├── 1: Barely noticed
└── How much does it hurt?
Frequency (1-5):
├── 5: Touch daily
├── 4: Touch weekly
├── 3: Touch monthly
├── 2: Touch quarterly
├── 1: Rarely/never
└── How often do we encounter it?
Risk (1-5):
├── 5: Security vulnerability
├── 4: Data loss potential
├── 3: Service outage risk
├── 2: Minor degradation
├── 1: No risk
└── What could go wrong?
Effort (1-5):
├── 5: Months of work
├── 4: Multiple sprints
├── 3: Full sprint
├── 2: Few days
├── 1: Hours
└── How hard to fix?
PRIORITY SCORE:
─────────────────────────────────────
Formula:
Priority = (Impact + Frequency + Risk) / Effort
Example:
Legacy auth system:
├── Impact: 4
├── Frequency: 4
├── Risk: 5
├── Effort: 4
├── Score: 13/4 = 3.25
└── High priority
Unused utility function:
├── Impact: 1
├── Frequency: 1
├── Risk: 1
├── Effort: 1
├── Score: 3/1 = 3.0
└── Quick win, but low value
Priority Buckets
Organizing Debt
PRIORITY BUCKETS
════════════════
CRITICAL (Now):
─────────────────────────────────────
├── Security vulnerabilities
├── Data loss risk
├── Blocking feature work
├── Production incidents
├── Address immediately
└── Drop other work
HIGH (This Quarter):
─────────────────────────────────────
├── Major productivity impact
├── Frequently encountered
├── Growing worse
├── Plan and schedule
└── Dedicated time
MEDIUM (Backlog):
─────────────────────────────────────
├── Moderate impact
├── Occasional friction
├── Stable (not worsening)
├── Address opportunistically
└── When in the area
LOW (Someday/Maybe):
─────────────────────────────────────
├── Minor impact
├── Rarely encountered
├── Not getting worse
├── May never address
└── Don't invest now
IGNORE:
─────────────────────────────────────
├── In code being replaced
├── Never touched
├── Theoretical concerns
├── Premature optimization
├── Not worth tracking
└── Accept and move on
Making Decisions
Trade-off Analysis
DECISION MAKING
═══════════════
WHEN TO ADDRESS NOW:
─────────────────────────────────────
Address immediately when:
├── Blocking current feature
├── Security risk
├── Getting worse rapidly
├── Low effort, high impact
├── Team agrees it's painful
└── Clear ROI
WHEN TO DEFER:
─────────────────────────────────────
Defer when:
├── Area not being changed
├── System being replaced
├── High effort, unclear benefit
├── Not causing real problems
├── Other priorities more urgent
└── Opportunity cost too high
WHEN TO NEVER:
─────────────────────────────────────
Don't fix when:
├── Legacy system end-of-life
├── Rarely touched code
├── Cost exceeds benefit
├── Theoretical perfection
├── "Nice to have" only
└── Accept imperfection
TRADE-OFF QUESTIONS:
─────────────────────────────────────
Ask:
├── What's the cost of NOT fixing?
├── What features are we NOT building?
├── How much slower are we really?
├── Is this actually hurting?
├── What's the trend?
└── Honest assessment
Sprint Integration
Regular Investment
SPRINT INTEGRATION
══════════════════
SUSTAINABLE ALLOCATION:
─────────────────────────────────────
Options:
Percentage approach:
├── 15-20% of sprint capacity
├── Every sprint
├── Consistent investment
├── Never zero
└── Sustainable
Dedicated sprints:
├── 1 in 4 sprints = tech debt
├── Full focus
├── Larger refactoring
├── Quarterly cadence
└── Concentrated effort
Boy Scout Rule:
├── Leave code better than found
├── Small improvements continuously
├── Part of feature work
├── No separate tracking
└── Cultural habit
SPRINT PLANNING:
─────────────────────────────────────
Include debt:
├── Tech debt items in backlog
├── Prioritized like features
├── Included in sprint
├── Team picks what to address
└── Visible commitment
BALANCING:
─────────────────────────────────────
Sprint composition:
├── Feature work: 70-80%
├── Bug fixes: 5-10%
├── Tech debt: 10-20%
├── Continuous improvement
└── Healthy balance
Tracking Debt
Visibility
TRACKING TECHNICAL DEBT
═══════════════════════
DEBT BACKLOG:
─────────────────────────────────────
Dedicated tracking:
├── Label: tech-debt
├── Category labels
├── Priority assigned
├── Effort estimated
├── Visible backlog
└── Tracked like features
GITSCRUM SETUP:
─────────────────────────────────────
├── Tech debt label
├── Debt category labels
├── Priority field
├── Regular grooming
├── Sprint inclusion
└── Treated seriously
DEBT REGISTER:
─────────────────────────────────────
Document:
│ Item │ Impact │ Effort │ Priority │
├──────────────┼────────┼────────┼──────────┤
│ Auth refactor│ High │ High │ Q2 │
│ Test coverage│ Medium │ Medium │ Ongoing │
│ API cleanup │ Low │ Low │ Someday │
REGULAR REVIEW:
─────────────────────────────────────
├── Quarterly debt review
├── Update priorities
├── Remove completed
├── Add new discoveries
├── Keep current
└── Living document
Communication
Stakeholder Buy-in
STAKEHOLDER COMMUNICATION
═════════════════════════
EXPLAINING DEBT:
─────────────────────────────────────
Business terms:
├── "Shipping features takes 30% longer"
├── "We have 2x more bugs in this area"
├── "Security risk if not addressed"
├── "Slows every developer"
└── Impact they understand
NOT:
├── "The code is ugly"
├── "It's not using best practices"
├── "I don't like how it was done"
├── "It's not modern"
└── Technical complaints
MAKING THE CASE:
─────────────────────────────────────
Show impact:
├── Time spent on workarounds
├── Bug frequency in area
├── Onboarding difficulty
├── Velocity trend
└── Data over opinions
Propose solution:
├── Specific investment
├── Expected improvement
├── Timeline
├── Trade-offs
└── Clear ask
GETTING APPROVAL:
─────────────────────────────────────
├── Small, consistent investment
├── Easier to approve than big bang
├── Show results over time
├── Build trust
└── Sustainable approach
Best Practices
For Tech Debt Prioritization
Anti-Patterns
PRIORITIZATION MISTAKES:
✗ Fix everything
✗ Fix nothing
✗ Big bang rewrites
✗ Only address in crisis
✗ Prioritize by opinion
✗ No visibility
✗ Technical purity focus
✗ Ignoring until too late