Should bugs and technical tasks be estimated in story points?
Our team spends about 30% of each sprint fixing bugs and doing technical tasks (database migrations, dependency updates, refactoring).
Right now we only use story points for user-facing features. Bugs and tech tasks just get done, but they eat into our capacity to deliver features. This makes our velocity look inconsistent.
Should we estimate bugs and technical tasks with story points too? Or is there a better way to track this work? Some people on the team think story points should only be for features.
Yes, absolutely estimate bugs and technical tasks in story points if they consume sprint capacity. Here's why and how:
Why Estimate Everything
- Velocity accuracy: If 30% of your work isn't counted, your velocity is meaningless
- Capacity planning: You need to know total team capacity, not just feature capacity
- Predictability: Stakeholders need realistic forecasts including all work types
- Trend tracking: See if bug rate is increasing (technical debt accumulation)
How to Estimate Bugs
Bugs can be estimated just like features based on complexity:
- 1-2 points: Simple fix, clear root cause (typo, config change)
- 3-5 points: Investigation needed, moderate complexity
- 8+ points: Reproduction unclear, deep system issue, requires refactoring
How to Estimate Technical Tasks
- 2-3 points: Dependency update, schema change
- 5-8 points: Database migration with data cleanup
- 13+ points: Major refactoring, architectural change
Alternative Approach: Capacity-Based Planning
Some teams use a hybrid model:
- Features: Estimated in story points
- Bugs/Tasks: Estimated in hours or fixed percentage (e.g., reserve 20% capacity)
This works but requires discipline to track both metrics.
What NOT to Do
- ❌ Don't exclude bugs from sprint planning entirely
- ❌ Don't count all bugs as "1 point" (they vary wildly)
- ❌ Don't add bugs mid-sprint without removing equal points
Recommended Approach for Your Team
Since you're already experiencing 30% capacity consumption:
- Start estimating bugs and tasks in story points
- Include them in sprint planning just like features
- Track feature velocity separately if stakeholders want to see "feature delivery rate"
- After 3 sprints, review: does it improve predictability?
Your velocity will initially drop (because you're now counting all work), but it will be accurate and stable.
We estimate bugs but use a simplified scale: Small (2), Medium (5), Large (8). Most bugs are Small. If we can't tell if it's Small or Medium during planning, it's automatically a Medium.
This keeps planning moving fast. We don't spend 10 minutes debating if a bug is a 3 or a 5.
This makes total sense. I'll propose we start estimating all work types in our next sprint planning. The simplified S/M/L scale for bugs sounds like a good compromise for speed.
Thanks for the detailed explanation!
One thing to watch: if your bug points are consistently increasing sprint-over-sprint, you have a quality problem. We track "bug ratio" (bug points / total points) as a quality metric.
Healthy teams: 10-20% bug work
Warning zone: 30-40%
Crisis: 50%+
If you're above 30% consistently, you need to address root causes, not just fix symptoms.