Scope Creep Examples — Web development
One more QA round, after the revision limit is already used up
Two rounds of bug-fix/QA revisions were scoped and closed out. The client opens a third round of tickets — none of them are new bugs, all of them are new preferences.
The SOW scoped two rounds of QA/revision on the build, and the client signed off on round two in the project management tool with "ready to launch." A week before go-live, five new tickets land: rename a button, change a spacing value, swap an icon. None are defects against the original spec — they're the kind of polish feedback that round one and round two existed to catch. The client isn't being unreasonable on any single ticket; the pattern is what's out of scope.
Clause typically implicated
Clause typically implicated
Revision limit clause→ — Applies to development the same way it applies to design — a fixed number of feedback/fix rounds, not an open-ended QA relationship.
Suggested change-order wording
Suggested change-order wording (illustrative, not legal advice)
These five tickets are style preferences rather than defects against the approved spec, and round two (already closed) covered the included QA rounds under our agreement. We're glad to make these changes as a scoped follow-on — estimated at [X] hours at [rate], or bundled into next sprint if you'd prefer to hold launch. Which would you like to do?
How this usually resolves
Development teams often eat these tickets to avoid delaying launch, which is a reasonable one-time call — but it works best made explicitly, with the client told it's a courtesy this time rather than silently absorbed as if it were always included. Otherwise the next project's QA round quietly becomes three rounds instead of two.
Related reading