6 min read • Guide 514 of 877
How to Manage Technical Debt with GitScrum Effort Points
Technical debt accumulates silently until it cripples delivery velocity. GitScrum's effort point system enables teams to quantify debt items alongside feature work, making the true cost visible to stakeholders and enabling data-driven decisions about when and what to pay down.
Technical Debt Estimation
| Debt Type | Complexity Factors | Typical Points |
|---|---|---|
| Simple refactor | Single file, well-tested | 1-2 |
| Module improvement | Multiple files, tests needed | 3-5 |
| Component redesign | Cross-module, breaking changes | 8-13 |
| Architecture change | System-wide, migration needed | 13-21+ |
Debt Tracking with Effort Points
TECHNICAL DEBT INVENTORY
┌─────────────────────────────────────────────────┐
│ DEBT BACKLOG STRUCTURE │
│ │
│ Epic: Technical Debt Reduction Q1 │
│ │
│ Category: Database (Total: 34 points) │
│ ├── [5 pts] Migrate to connection pooling │
│ ├── [8 pts] Add missing indexes │
│ ├── [13 pts] Refactor ORM usage │
│ └── [8 pts] Implement query caching │
│ │
│ Category: API Layer (Total: 21 points) │
│ ├── [3 pts] Standardize error responses │
│ ├── [5 pts] Add input validation │
│ ├── [8 pts] Implement rate limiting │
│ └── [5 pts] Add API versioning │
│ │
│ Category: Frontend (Total: 26 points) │
│ ├── [8 pts] Replace legacy state management │
│ ├── [5 pts] Extract shared components │
│ ├── [8 pts] Add TypeScript strict mode │
│ └── [5 pts] Improve bundle splitting │
│ │
│ TOTAL DEBT BACKLOG: 81 points │
└─────────────────────────────────────────────────┘
Sprint Capacity Allocation
SPRINT PLANNING WITH DEBT ALLOCATION
TEAM VELOCITY: 40 points/sprint
┌─────────────────────────────────────────────────┐
│ CAPACITY SPLIT: │
│ │
│ Feature Development: 28 points (70%) │
│ ├── User stories │
│ └── New functionality │
│ │
│ Technical Debt: 8 points (20%) │
│ ├── Refactoring │
│ ├── Test improvements │
│ └── Architecture updates │
│ │
│ Maintenance: 4 points (10%) │
│ ├── Bug fixes │
│ └── Dependency updates │
└─────────────────────────────────────────────────┘
SPRINT DEBT SELECTION CRITERIA:
┌─────────────────────────────────────────────────┐
│ Priority order: │
│ 1. Debt blocking planned features │
│ 2. Debt causing production issues │
│ 3. Debt slowing velocity │
│ 4. Debt with security implications │
│ 5. Quick wins (high impact, low effort) │
└─────────────────────────────────────────────────┘
Debt Point Estimation Guide
EFFORT POINT ESTIMATION FOR DEBT
1 POINT - Trivial
┌─────────────────────────────────────────────────┐
│ • Rename for clarity │
│ • Add missing null check │
│ • Update outdated comment │
│ • Fix simple code smell │
│ Time: < 2 hours │
└─────────────────────────────────────────────────┘
2-3 POINTS - Simple
┌─────────────────────────────────────────────────┐
│ • Extract method/function │
│ • Add missing tests for single function │
│ • Replace deprecated library call │
│ • Fix single file code duplication │
│ Time: 2-4 hours │
└─────────────────────────────────────────────────┘
5 POINTS - Medium
┌─────────────────────────────────────────────────┐
│ • Refactor a class/module │
│ • Add test coverage for component │
│ • Replace pattern across multiple files │
│ • Extract shared utility │
│ Time: 1-2 days │
└─────────────────────────────────────────────────┘
8 POINTS - Large
┌─────────────────────────────────────────────────┐
│ • Refactor cross-module dependency │
│ • Replace deprecated library │
│ • Add caching layer │
│ • Significant test infrastructure change │
│ Time: 2-4 days │
└─────────────────────────────────────────────────┘
13 POINTS - Very Large
┌─────────────────────────────────────────────────┐
│ • Component architecture redesign │
│ • State management overhaul │
│ • Database schema migration │
│ • Major version upgrade (framework) │
│ Time: 1-2 weeks │
└─────────────────────────────────────────────────┘
Debt Metrics Dashboard
TECHNICAL DEBT HEALTH
DEBT INVENTORY:
┌─────────────────────────────────────────────────┐
│ Total debt backlog: 81 points │
│ Critical debt: 21 points (26%) │
│ High priority: 34 points (42%) │
│ Normal priority: 26 points (32%) │
└─────────────────────────────────────────────────┘
SPRINT PROGRESS:
┌─────────────────────────────────────────────────┐
│ Sprint Added Removed Net Change │
│ ───────────────────────────────────────────── │
│ Sprint 14 5 pts 8 pts -3 pts ↓ │
│ Sprint 15 3 pts 10 pts -7 pts ↓ │
│ Sprint 16 8 pts 6 pts +2 pts ↑ │
│ Sprint 17 2 pts 12 pts -10 pts ↓ │
│ ───────────────────────────────────────────── │
│ Quarter 18 pts 36 pts -18 pts ↓ │
└─────────────────────────────────────────────────┘
VELOCITY IMPACT:
┌─────────────────────────────────────────────────┐
│ Before debt reduction: 32 pts/sprint │
│ After debt reduction: 40 pts/sprint (+25%) │
│ │
│ Debt investment: 32 points over 4 sprints │
│ Velocity gain: 8 pts × 4 sprints = 32 points │
│ ROI: Already positive, continuing to grow │
└─────────────────────────────────────────────────┘
Best Practices
- Estimate debt like features using same point scale
- Allocate consistent capacity (15-25% per sprint)
- Track debt backlog separately but visibly
- Prioritize debt by impact on velocity and quality
- Celebrate debt reduction as team achievement
- Measure velocity improvements from debt work
- Add context to debt items (why it matters)
- Avoid debt bankruptcy through consistent payments
Anti-Patterns
✗ Not estimating debt items
✗ No dedicated debt capacity
✗ Debt only when "we have time"
✗ Large debt items without breakdown
✗ No tracking of debt added vs removed
✗ Treating debt as lesser work