How to estimate bugs
By Thimira Dulakshitha Kularatne · Updated
Bugs are awkward to estimate: the fix might take ten minutes, but finding the cause could take days. Teams disagree on whether bugs should get story points at all. Here are the two common approaches, what each does to your velocity, and practical rules that work either way.
Two ways to handle bugs
1. Point bugs like stories
Bugs go through planning poker with everything else. The sprint plan reflects all the work the team takes on, and velocity includes bug fixing.
Watch out: velocity can look healthy while the team is mostly fixing its own defects.
2. Don’t point bugs
Bugs get no points. Velocity measures only new functionality, and the team leaves room in each sprint for bug work (for example, plan to 80% of the usual velocity).
Watch out: a buggy sprint shows up as lower velocity, which can be confusing if nobody explains why.
A common middle ground: point bugs that are found before a story is done as part of that story, and treat bugs that escape into production as their own backlog items, pointed like any other work.
Estimating when you don’t know the cause
- Reproduce the bug and write down the steps, the expected result and the actual result.
- If the cause is obvious, estimate the fix with planning poker like any story. Include testing and any data clean-up in the size.
- If the cause is unknown, create a time-boxed investigation first. This is a spike: its goal is an answer, not a fix.
- Once the investigation finds the cause, estimate the fix as its own item.
Practical rules
- Reproduce before you size. A bug you can’t reproduce is a research task, not a fix. Don’t put a number on it until someone has seen it happen.
- Size the fix, not the severity. A checkout outage can be a one-line fix; a cosmetic glitch can hide a tangled root cause. Severity decides priority. Size is a separate question.
- Time-box the unknowns. When nobody knows the cause, agree a time-box for investigation (say half a day). If the cause is found, estimate the fix. If not, decide together whether to keep digging.
- Batch the small ones. Ten tiny bugs don’t need ten estimation rounds. Group them into one “bug bash” item, or keep a fixed slice of each sprint for them.
- Use the ? card honestly. If the cards come back as ?, or spread from 1 to 13, the team doesn’t understand the bug yet. That’s a signal to investigate, not to average.
Questions
Should bugs have story points?
Either approach works if the team is consistent. Pointing bugs makes the sprint plan reflect all the work. Not pointing them makes velocity measure only new value delivered, with capacity for bugs reserved separately.
How do you estimate a bug when you don’t know the cause?
Split it in two: a time-boxed investigation (often run as a spike) to find the cause, then an estimate for the fix once you know what it is.
What about production incidents?
Fix urgent incidents straight away and don’t wait for an estimation round. Estimate any follow-up work, such as a proper fix or preventive changes, as normal backlog items.
Size your bug backlog together
Paste your bug list into Benchmark’s job board, estimate them one by one or collect votes async, and export the results to your tracker. Private notes let people say “I think it’s the cache” before the reveal, without steering anyone else’s card.