Scope Creep
The gradual expansion of a project's scope beyond its original boundaries — through uncontrolled feature additions, unclear requirements, or stakeholder requests — without adjusting timeline or resources.
What is Scope Creep?
Scope creep is the gradual, often uncontrolled expansion of a project's scope after work has begun. It's the accumulation of small "while we're at it..." additions that collectively delay delivery, inflate cost, and erode team focus.
Common causes
| Cause | Example |
|---|---|
| Vague requirements | "Make it better" → team makes 10 things without a shared goal |
| Stakeholder additions mid-sprint | "Can we also add CSV export?" halfway through the sprint |
| Gold plating | Engineers adding features not in the spec because they seem useful |
| No explicit non-goals | Assumptions fill the vacuum where scope wasn't defined |
How to prevent it
- Write explicit non-goals in every PRD — "we are not building X in this version"
- MoSCoW every release — items not in Must/Should are explicitly deferred
- Change control process — new scope requires explicit owner, timeline impact, and sign-off
- Protect the sprint goal — any addition mid-sprint requires removing equivalent scope
When to say yes to scope changes
Scope changes are sometimes right. Say yes when: the change directly supports the sprint goal, the impact on delivery is explicitly acknowledged, and an equivalent item is removed.
Free templates for Scope
Frequently asked questions
Is scope creep always bad?
Uncontrolled scope creep is bad. Managed scope change — where the impact is acknowledged and something else is cut or deferred — is normal product management. The problem is invisible expansion, not evolution.
Who is responsible for preventing scope creep?
The PM owns the scope definition and the non-goals. Engineering owns flagging when new requests add effort. Stakeholders own the decisions when tradeoffs are presented. Scope creep usually happens when one of these three fails.
Apply Scope Creep to your real product data
PMRead ingests customer feedback, interviews, and Slack threads — and generates PRDs grounded in real evidence.
Related terms
PRD (Product Requirements Document)
A written document that describes what a product or feature should do, why it exists, and how success will be measured — before engineering begins.
MoSCoW Method
A prioritization technique that classifies requirements into four categories — Must Have, Should Have, Could Have, and Won't Have — to scope a release against a fixed deadline.