How do you separate bugs from scope changes after launch?
Most post-launch fights start with one bad label: “bug.”
A client says, “This doesn’t work.”
A builder hears, “Fix it for free.”
But “it doesn’t work” can mean:
- The product contradicts agreed behavior.
- The agreed work was never delivered.
- The customer now wants new behavior.
Only the first is a bug.
The other two are scope decisions.
When all three land in one ticket queue, someone ends up doing unpaid work.
How does your team separate them?
Useful rule: classify against an acceptance example before it reaches the backlog. Ask: “What exact user action and result were agreed?”
Attach the original acceptance note and a short screen recording to the classification so it feels like a shared decision, not a billing argument. A short post-launch warranty can cover documented defects; new behavior should always get its own estimate and approval.
That’s a very practical rule.
I like the shift from “Is this a bug?” to “What did both sides actually agree would happen?”
The acceptance sheet plus a short recording also makes the distinction verifiable, not just debatable.
For a delivery gap, do you treat it as a separate workflow from a bug, or do both follow the same remediation path?
I use separate lanes after a shared triage step. The evidence packet is the same: acceptance example, recording, and a reproduction check. A defect then gets an incident owner, severity, and remediation deadline; a delivery gap gets a completion plan and a fresh acceptance review. Both end with client confirmation, but separating them keeps a delivery miss from being treated like a blame issue.