In short
Prevent scope creep by defining outcomes, launch scope, non-objectives, assumptions, and acceptance criteria; appointing one decision owner; separating defects, clarifications, and new requirements; and requiring every change to show its effect on cost, date, risk, or existing scope. The goal is controlled learning—not refusing all change.
First classify the change
| Type | Example | Treatment |
|---|---|---|
| Defect | Agreed permission rule fails | Correct within agreed quality terms |
| Clarification | Copy makes an accepted rule explicit | Assess within existing scope |
| Missing requirement | Critical failure state was never defined | Decide responsibility and consequence |
| New requirement | Add a second approval workflow | Trade cost, date, or scope |
| Discovery | User evidence invalidates the approach | Replan intentionally |
Calling everything “scope creep” punishes learning. Calling everything “just a small change” destroys the plan.
Establish boundaries
Before delivery, define:
- intended outcome;
- must-launch workflows;
- non-objectives;
- acceptance criteria;
- assumptions and dependencies;
- decision-maker;
- budget and date constraints;
- change process.
Boundaries make change visible. They do not predict every detail.
Keep three lists
- Committed: approved for the current release.
- Candidate: valuable, not yet committed.
- Evidence needed: problem or solution remains uncertain.
Ideas can enter the candidate list without interrupting active work. Review them at a regular decision point.
Use a short change record
For each proposed change, record:
- request and reason;
- evidence;
- affected workflows, data, design, code, testing, migration, and operations;
- estimate range;
- date and risk effect;
- what is removed or deferred;
- decision and owner.
A one-line feature can cross every layer of the product.
Protect feedback quality
Consolidate stakeholder feedback and ask which objective or evidence supports it. Separate personal preference from a requirement and resolve contradictory comments before sending them to the team.
Common questions
Is scope creep always bad?
Uncontrolled scope creep is harmful. Evidence-led change can improve the product when its consequences and trade-offs are explicit.
Who approves scope changes?
One accountable product or business owner should approve after delivery and technical owners explain the effect.
Should every change increase the budget?
No. Some clarify or correct agreed work. Genuine additions must change budget, date, or existing scope unless unused capacity exists.
How do agile teams prevent scope creep?
They maintain prioritised backlogs and release boundaries, limit work in progress, and make commitment decisions continuously rather than accepting everything.
What is the earliest warning sign?
New work enters active delivery without a named decision, updated acceptance criteria, or an explicit trade-off.
