Estimating a bug with no repro
How to estimate a bug with no repro: you can't size the fix, only the search. How to time-box the investigation instead of voting on a story nobody can see.
If you can’t reproduce it, you can’t estimate it. You can estimate looking for it.
A bug with no repro is two unknowns wearing one ticket. The first unknown is the cause: there’s a symptom in production but no reliable way to trigger it locally, no consistent stack trace, no line in the logs that always precedes it. The second unknown is the fix, which depends entirely on the first. Voting a number on the fix before the cause is known is voting on a story the team can’t actually see.
The fix isn’t always hard once you find the cause — it’s often a one-line change. The expensive part is the finding. Estimating the search is honest; estimating the fix is wishful.
What gets said in the room
Engineer A: “I think it’s the cache invalidation.”
Engineer B: “I think it’s a race in the worker.”
Lead: “Has anyone been able to make it happen on demand?”
QA: “We’ve tried twenty things. Nothing reliable.”
Support: “It’s three users a week, always Tuesday afternoons.”
Questions worth asking before voting
- What’s the symptom, and how often does it appear?
- Have we got logging on the suspected paths, or do we need to add it first?
- Is there a customer with a known-bad account we can reproduce against?
- What’s the customer cost of the bug per week — and does it justify a deep dive?
- What’s the time-box on the investigation before we revisit?
Two named theories and no repro isn’t a number to settle — it’s a search to fund. Give it a budget and a checkpoint, then re-estimate once the cause has a name.
Vote a search budget. When the cause has a name, estimate the fix on its own.
See estimating a flaky test for the same shape, and common planning-poker mistakes on estimating bugs at feature precision. Browse the other worked estimation examples, or open a free planning poker session when the cause is known.