How to Estimate Bug Fixes in Your Backlog
Bugs resist estimation more than features do. A bug that looks like a one-line fix can turn into a two-day archaeology project. Here's how to approach bug sizing without pretending you have certainty you don't.
Why bugs are different from features
Features have defined acceptance criteria. Bugs have a symptom and an unknown root cause. Until you've investigated, you don't know if the fix is in one place or ten.
Two-stage approach: investigation first
Split significant bugs into two stories:
- Investigation: timebox the root cause analysis. "Spend up to 2 hours identifying why this happens and what a fix would require." Output: a clear diagnosis and a scope estimate.
- Fix: estimate after investigation, when you know what needs to change.
For trivial bugs (typos, obvious off-by-one errors), skip the split and estimate directly.
Classification by confidence
Before estimating, classify the bug:
- Known cause, known fix: estimate it like a small feature. The path is clear.
- Known cause, unknown fix: spike first. The cause is diagnosed but the solution isn't obvious.
- Unknown cause: investigation story only. Don't estimate the fix until you know what's broken.
Accounting for regression risk
Some fixes are simple but risky - touching a module that's connected to many others. Estimate should account for the testing overhead, not just the code change. A one-line fix in a payment processor might warrant an 8 because of the care required around it.
Handling bug load in sprint planning
Many teams reserve 10-15% of sprint capacity for bug work, treated as a pool rather than as individually planned stories (the same pattern works for technical debt). This prevents bug investigations from consuming the whole sprint when they run long.
Estimating bugs honestly means acknowledging that you often don't know what you're estimating yet. Build the investigation into the process rather than hoping the unknown stays bounded.