Estimating a customer-reported bug
How to estimate a customer-reported bug: the account on the ticket decides the size. How to separate the one-line fix from the response that eats the sprint.
The bug isn’t the size. The customer is the size.
A customer-reported bug carries scope the team can’t see from the ticket alone. The technical fix might be a one-liner. But the surrounding work — reproducing on the customer’s data, writing a postmortem, drafting the response, deciding whether to credit the account, communicating to other affected customers — is often most of the story. None of it is on the ticket. All of it eats velocity.
Estimate two things: the fix, and the response. The fix is normal planning poker. The response is unfamiliar for engineering teams and gets systematically under-sized — which is why customer bugs feel like they bleed through the sprint even when the deck-vote was small.
What gets said in the room
Backend: “The fix is one line.”
PM: “Which account reported it?”
Support: “Their CSM is asking for an RCA by Friday.”
Lead: “Are other accounts affected? Do we need to email them?”
QA: “Can we repro on their data, or do we need a sanitised export?”
Questions worth asking before voting
- Who reported it, and what’s their ARR, SLA, or contract status?
- Is an RCA or postmortem owed externally?
- Are other accounts affected, and how do we find out?
- Do we need to credit, refund, or extend a trial?
- Who writes the customer-facing response, and is that on this ticket?
- Reproduction: customer’s data, sanitised dump, or synthetic?
Splitting helps: the fix is one ticket, the response is another. Both go through planning poker; only one of them is engineering-shaped.
Estimate the fix and the response separately. The account name is what makes the response big.
See common planning-poker mistakes on the failure mode of voting on work the room doesn’t own. Browse the other worked estimation examples, or open a free planning poker session with both stories ready.