How to Estimate Bugs and Maintenance Tasks
Bugs don’t get planned into the backlog. When they appear, the team needs to decide: do we fix it now or later? And how long will it take?
The Problem with Estimating Bugs Using Story Points
Story points measure relative complexity of new features. Bugs are not features. Comparing the complexity of “building checkout” with “debugging error 500” is comparing apples and oranges.
Approaches for Estimating Bugs
1. T-Shirt Sizing for Bugs
- XS — typo, wrong label (5–30 min)
- S — simple bug, known cause (1–2 hours)
- M — bug requiring investigation (2–4 hours)
- L — complex bug, possible refactoring (4–8 hours)
- XL — systemic bug, possible rewrite (1+ day)
2. Historical Lead Time
“Of the last 30 bugs, the ‘M’ ones took 3 hours on average. This one seems like an M.”
3. Investigation Timeboxing
When the cause is unknown:
“Let’s timebox 1 hour to investigate. After that, we decide whether to estimate the fix or create a spike.”
4. No Estimate — Just Fix It
For critical bugs (production, security):
“No matter how long it takes, fix it now.” After the fix, record the lead time for future reference.
Bug Budget vs. Sprint Interruption
Bug Budget (Recommended)
Reserve 15–20% of sprint capacity for bugs. Within this budget, the team prioritizes.
“We have 5 points of bug budget. This bug is 3 points. It fits in the sprint.”
Sprint Interruption
If the bug is critical and doesn’t fit the budget:
- PO decides what comes out of the sprint to make room for the bug
- “To add this 8-point bug, we remove the 5-point search task and part of the 3-point report.”
Bug Reference Table
| Type | Typical Size | When to Estimate | When to Just Fix |
|---|---|---|---|
| Cosmetic | XS | Always | — |
| Simple functional | S | Always | — |
| Complex functional | M–L | If not urgent | If critical |
| Systemic/security | XL | Never | Always now |
| Performance | M–XL | After diagnosis | If high impact |
Prevention: Recurring Bugs
If 40% of bugs are the same type (e.g., NPEs in production), invest in prevention:
“Every sprint, 3 points are spent on NPEs. If we add optional chaining to the team standard (5 points), we save ~15 points over 5 sprints.”
Bug Metrics
Track per sprint:
- Count — how many bugs were reported
- Bugs per module — where are the problems?
- Average lead time — how long to resolve?
- Bug rate — bugs per delivered feature
- Reopen rate — how many bugs came back after being marked “fixed”?
Conclusion
Bugs should not be estimated with the same ruler as features. Use T-Shirt sizing, historical lead time, or simply fix and record the time afterward. The important thing is to have a bug budget so sprint features don’t get inflated.