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.
The Non-Feature Work Problem
Most agile training focuses on feature estimation. But real teams spend 20-40% of time on:
- Bug fixes (production incidents, customer-reported defects)
- Technical debt (refactoring, upgrading dependencies)
- Infrastructure (CI/CD improvements, monitoring)
- Documentation (architecture diagrams, API docs)
If you only point features, velocity only tracks 60-80% of work. Forecasts become fiction.
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
- Simple: one backlog, one velocity metric
- Reflects reality that maintenance competes with features
Cons:
- Hard to separate feature velocity from maintenance
- Stakeholders complain: "Why did velocity drop?" (Answer: more bugs this sprint)
- Can't predict maintenance-heavy sprints
Best for: Small teams, startups, teams with stable bug rates
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 visible to stakeholders
- Can forecast feature work independently
- Encourages treating bugs seriously (not hidden in velocity)
Cons:
- Complex sprint planning (two backlogs to manage)
- Bugs still take time—ignoring that in capacity planning causes overcommitment
- Requires dual tracking systems
Best for: Large organizations, regulated industries, teams with separate QA
3. Capacity Allocation (Percentage Model)
Reserve 20-30% of sprint capacity for unestimated maintenance. Only features are pointed.
Pros:
- Simple planning: estimate features only
- Acknowledges maintenance without estimating every small fix
- Works well when bug arrival is unpredictable
Cons:
- Can't predict maintenance-heavy sprints (20% allocation, 40% actual)
- No data on maintenance velocity trends
- Hides maintenance cost from stakeholders
Best for: Mature products with predictable maintenance load
Best Practice: Point If >1 Hour
Here's a pragmatic hybrid rule that works for most teams:
<1 Hour Bug Fix: No Points, Just Fix It
Typo fixes, one-line changes, obvious configuration issues. Don't slow down to estimate. Just fix, commit, move on.
Track these separately if you want (count of fixes), but don't include in velocity.
1-8 Hour Bug: Estimate Like Any Story
If it takes meaningful time (more than an hour), it deserves estimation. Use same Fibonacci scale as features.
Example: "Fix race condition in checkout flow" = 5 points (investigation + fix + testing).
Tech Debt: Always Point
Refactoring is planned work with clear scope. "Extract authentication logic to shared module" = 8 points.
Unlike emergency bugs, tech debt is chosen work. Estimate it to make cost visible to stakeholders.
Infrastructure: Point and Label
"Set up automated DB backups" = 5 points. Label as "infrastructure" so you can track separately from features.
Calibrating Maintenance Estimates
Use Same Baseline as Features
Your "reference 5-point story" should apply to bugs too. If "Add email validation" is 5 points, and "Fix email validation race condition" has similar complexity, it's also 5 points.
Complexity doesn't change based on story type.
Include Full Scope
Bug fix estimate includes:
- Root cause investigation
- Code changes
- Testing (especially regression testing)
- Deployment and verification
- Documentation if needed
Don't just estimate coding time. Estimate end-to-end work.
Account for Uncertainty
Bugs often have higher uncertainty than features. "Sometimes users can't log in" might be 3 points or 13 depending on root cause.
If uncertainty is high, estimate higher or spike first to investigate before estimating fix.
Tracking Maintenance Patterns
Calculate Feature vs. Maintenance Ratio
Over 5 sprints, track:
- Total velocity: 120 points
- Feature work: 85 points (71%)
- Bug fixes: 25 points (21%)
- Tech debt: 10 points (8%)
This data helps forecast: "We average 25 points/sprint, but only 18 points go to features."
Identify Maintenance Trends
If bug points increase sprint over sprint, that's a quality signal. Address root causes:
- More unit tests?
- Code review process failing?
- Complexity in certain modules?
Don't just accept rising maintenance cost—investigate and fix.
Communicate to Stakeholders
"Why is velocity down this sprint?" becomes "Velocity is 25 points as usual, but 12 points went to critical bug fixes. Feature delivery was 13 points."
Data answers stakeholder questions and protects team from unfair pressure.
Common Anti-Patterns
Inflating Bug Estimates to "Punish" Quality Issues
Estimating bugs high to "prove" there's a quality problem. Estimates should reflect actual complexity, not send messages.
Use metrics to communicate quality issues, not estimation manipulation.
Pointing Bugs, Not Pointing Refactoring
Inconsistency. Both are non-feature work. Estimate both or estimate neither.
Treating All Bugs as 1 Point
"Bugs are small" assumption. Some bugs take longer than features. Estimate based on actual complexity.
Not Tracking What Velocity Includes
If someone looks at your velocity chart, can they tell what's included? Document your approach in team charter.
Recommended Approach for Most Teams
Estimate all work >1 hour:
- Features: pointed
- Bugs >1 hour: pointed with "bug" label
- Tech debt: pointed with "tech-debt" label
- Tiny fixes <1 hour: track count separately, don't point
Calculate segmented velocity:
- Total velocity: all pointed work
- Feature velocity: features only
- Maintenance velocity: bugs + tech debt
Forecast conservatively:
Use feature velocity (not total) for roadmap forecasting. If total velocity is 25 but feature velocity is 18, forecast with 18.
Start Consistent Estimation
Alignlee supports labeling work types (feature/bug/tech-debt) while estimating. Track segmented velocity automatically.