Estimating a bug with no repro
The story where the team confidently sizes a fix for a bug nobody has seen happen.
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?
Vote a search budget. When the cause has a name, estimate the fix on its own.
See flaky test for the same shape; common mistakes on estimating bugs at feature precision. Or open a session when the cause is known.