Estimating Technical Debt: Should Bugs Have Story Points?
Should you point bug fixes? What about refactoring? Tech debt repayment? Teams handle non-feature work inconsistently, making velocity tracking meaningless. Here's how to estimate maintenance work without distorting sprint metrics.
Three Approaches to Non-Feature Work
1. Point Everything (Most Common)
Bugs, tech debt, and features all get story points. Velocity includes all work types.
Pros: True picture of team capacity
Cons: Hard to separate feature velocity from maintenance
2. Separate Tracks (Enterprise Approach)
Bugs tracked separately from stories. Team commits to "20 story points + 3 bugs per sprint."
Pros: Clear feature delivery rate
Cons: Complex sprint planning, two backlogs to manage
3. Capacity Allocation (Percentage Model)
Reserve 20% of sprint capacity for unestimated maintenance. Only features are pointed.
Pros: Simple planning
Cons: Can't predict maintenance-heavy sprints
Best Practice: Point If >1 Hour
Simple rule:
- <1 hour bug fix: No points, just fix it
- 1-8 hour bug: Estimate like any story
- Tech debt: Always point—it's planned work