Technical Debt Management | 15-20% Capacity
Track and prioritize technical debt systematically. Allocate 15-20% of sprint capacity to prevent accumulation. GitScrum makes debt visible and actionable.
6 min read
Technical debt is inevitable—the question is whether you manage it or let it manage you. Untracked debt compounds silently until development grinds to a halt. Effective management means making debt visible, prioritizing strategically, and allocating consistent effort to reduce it.
Technical Debt Types
| Type | Description | Example |
|---|---|---|
| Intentional | Known shortcut for speed | Hardcoded config for MVP |
| Unintentional | Emerged over time | Spaghetti code evolution |
| Outdated | Was good, now isn't | Old framework version |
| Bit rot | Degraded from neglect | Unmaintained dependencies |
| Documentation | Missing/wrong docs | Outdated API docs |
Making Debt Visible
Tracking Technical Debt
TECHNICAL DEBT INVENTORY
════════════════════════
GITSCRUM DEBT TRACKING:
├── Create "Technical Debt" label
├── Tag all debt items consistently
├── Use board filter for debt view
├── Track in dedicated column or backlog
DEBT ITEM TEMPLATE:
─────────────────────────────────────
Title: [Clear description of debt]
Type: [Intentional/Unintentional/Outdated]
Location: [Files/services affected]
Impact: [How it affects development]
Risk: [What could go wrong]
Effort: [S/M/L estimate]
Trigger: [When should we fix this]
─────────────────────────────────────
EXAMPLE:
─────────────────────────────────────
Title: Auth module has no tests
Type: Unintentional (grew without TDD)
Location: /src/auth/*
Impact: High - Changes are risky, slow reviews
Risk: Auth bugs reach production
Effort: L (estimated 2 weeks)
Trigger: Before any auth changes
─────────────────────────────────────
Debt Dashboard
TECHNICAL DEBT DASHBOARD
════════════════════════
┌─────────────────────────────────────────────────────────┐
│ Technical Debt Overview │
├─────────────────────────────────────────────────────────┤
│ │
│ CURRENT STATE │
│ Total items: 47 │
│ Critical: 3 | High: 12 | Medium: 20 | Low: 12 │
│ │
│ BY CATEGORY │
│ ████████░░ Code: 23 (49%) │
│ ████░░░░░░ Testing: 9 (19%) │
│ ███░░░░░░░ Docs: 7 (15%) │
│ ██░░░░░░░░ Infra: 5 (11%) │
│ █░░░░░░░░░ Dependencies: 3 (6%) │
│ │
│ TREND │
│ Added this month: 8 │
│ Resolved this month: 11 │
│ Net change: -3 ↘ (improving) │
│ │
│ EFFORT INVESTED │
│ This sprint: 15% of capacity │
│ Target: 20% │
│ │
└─────────────────────────────────────────────────────────┘
Prioritization
Debt Prioritization Matrix
PRIORITIZATION FRAMEWORK
════════════════════════
SCORE EACH ITEM (1-5):
IMPACT: How much does it slow us?
├── 5: Blocks multiple features weekly
├── 4: Blocks work monthly
├── 3: Slows work regularly
├── 2: Occasional friction
└── 1: Minor inconvenience
RISK: What could go wrong?
├── 5: Security/data loss risk
├── 4: Production outage risk
├── 3: Significant bugs likely
├── 2: Minor bugs possible
└── 1: Cosmetic issues only
OPPORTUNITY: What does fixing enable?
├── 5: Enables major initiative
├── 4: Unblocks near-term feature
├── 3: Enables nice-to-have
├── 2: General improvement
└── 1: Minimal benefit
EFFORT: How hard to fix?
├── 1: Week+ of work
├── 2: Days of work
├── 3: 1-2 days
├── 4: Hours
└── 5: Quick fix
PRIORITY SCORE = Impact + Risk + Opportunity + Effort
Example:
Auth tests missing:
Impact: 4 + Risk: 4 + Opportunity: 3 + Effort: 2 = 13 (HIGH)
Prioritization Categories
DEBT PRIORITIZATION BUCKETS
═══════════════════════════
🔴 CRITICAL (Score 16-20):
├── Address immediately
├── Security or stability risk
├── Blocks critical path
└── Allocate dedicated sprint
🟠 HIGH (Score 12-15):
├── Schedule for next sprint
├── Include with related feature
├── Don't let accumulate
└── Regular attention
🟡 MEDIUM (Score 8-11):
├── Include in sprint planning
├── Opportunistic fixes
├── Address when touching area
└── Track but don't rush
🟢 LOW (Score 4-7):
├── Track for future
├── Fix if convenient
├── May never address
└── Re-evaluate periodically
Paying Down Debt
Allocation Strategies
DEBT ALLOCATION APPROACHES
══════════════════════════
APPROACH 1: Fixed Percentage
─────────────────────────────────────
Allocate 15-20% of each sprint to debt
├── Predictable capacity
├── Consistent progress
├── Team knows expectation
└── Won't eliminate large items quickly
Example: 80-point sprint → 16 points for debt
APPROACH 2: Debt Sprints
─────────────────────────────────────
Periodic all-debt sprint (quarterly)
├── Big chunks addressed
├── Team focus on quality
├── Can feel like break
└── Debt accumulates between
Example: Every 4th sprint is debt sprint
APPROACH 3: Boy Scout Rule
─────────────────────────────────────
Leave code better than you found it
├── Continuous improvement
├── No dedicated allocation
├── Integrated with features
└── May miss big items
Rule: 30 min improvement with each PR
APPROACH 4: Hybrid (Recommended)
─────────────────────────────────────
├── 15% sprint capacity (consistent)
├── Boy scout rule (continuous)
├── Annual debt sprint (major items)
└── Critical items get special allocation
Implementation Patterns
DEBT REDUCTION PATTERNS
═══════════════════════
STRANGLER FIG:
├── Build new system alongside old
├── Gradually migrate functionality
├── Eventually retire old system
├── Low risk, slower
REFACTOR IN PLACE:
├── Improve existing code
├── Maintain functionality
├── May need feature freeze
├── Faster but riskier
OPPORTUNISTIC:
├── Improve when touching code
├── Scope limited to task area
├── No dedicated time needed
├── Slow overall progress
BIG BANG:
├── Rewrite completely
├── Significant effort
├── High risk
├── Sometimes necessary
RULE OF THUMB:
├── Small debt: Opportunistic
├── Medium debt: Sprint allocation
├── Large debt: Strangler or dedicated sprint
└── Critical debt: Immediate attention
GitScrum for Debt Management
Tracking Setup
GITSCRUM DEBT MANAGEMENT SETUP
══════════════════════════════
LABELS:
├── tech-debt (main label)
├── debt:critical
├── debt:high
├── debt:medium
├── debt:low
CUSTOM FIELDS:
├── Debt Type: [dropdown]
├── Affected Area: [text]
├── Risk Level: [dropdown]
├── Created Date: [date]
VIEWS:
├── Tech Debt Dashboard (filtered view)
├── By Priority (sorted)
├── By Age (oldest first)
├── By Area (grouped)
AUTOMATION:
├── Age alert after 90 days
├── Remind when touching affected files
├── Include in sprint planning
└── Track resolution rate
Best Practices
For Technical Debt
Anti-Patterns
DEBT MANAGEMENT MISTAKES:
✗ Ignoring until crisis
✗ No tracking system
✗ All-or-nothing approach
✗ Feature-only sprints
✗ Big bang rewrites (usually)
✗ Prioritizing new over fix
✗ No visibility to stakeholders
✗ Debt as punishment