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.