A scope freeze protects a release outcome while allowing essential corrections. Evaluate each late request against what the release promises, rather than who requested it most recently.
Establish an entry rule
A fictional order portal must let customers see a reliable status. Displaying another customer's order blocks release. An annual reporting chart does not. The difference is the release promise and the consequence of failure.
| Request | Suggested treatment |
|---|---|
| Data or access boundary failure | Correct before opening access |
| Main workflow cannot complete | Fix or explicitly narrow the promise |
| Convenience improvement | Review for a subsequent release |
| Support for a new buyer segment | Re-scope separately |
Keep the trade-off visible
Record the request, its evidence and the decision. When something enters the release, identify what leaves or which date changes. An expanding scope with an unchanged estimate hides risk from everyone. Demonstrate the release using the scenarios agreed during planning.
What if a late request is genuinely important?
Compare the risk of shipping without it with the risk of implementing it hurriedly. A serious correction may justify delaying release. A useful improvement may fit a later iteration. A freeze is a decision mechanism, not a ban on learning. It should make consequences explicit before the team commits.
A launch promised to two regions
If a sales discussion introduces a second market shortly before release, list the additional language, support and operational requirements. Treat that as a scope decision. Merely making the interface available does not establish that the team can serve the new audience.
From this guide to your project
Product ↗
The experience connects your promise to the job your user needs to get done. We design that journey before adding more screens.
Tell us about your ideaExamples are educational and do not describe client results. Content prepared with AI assistance; see our editorial policy. Our method ↗