Estimating a customer-reported bug

The story whose size is decided by the account name on the ticket.

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 / 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. See estimating in absentia on the failure mode of voting on work the room doesn't own. Open a session with both stories ready.