Short answer
Scope creep is the gradual expansion of a project’s requirements after the scope is agreed, usually through small additions that each seem too minor to renegotiate. A single extra field on a form is trivial; the same field arriving eleven times, each with validation and a migration, is a schedule that no longer holds.
Also called: Requirements creep, Feature creep
The cause is rarely bad faith on either side. Requirements genuinely become clearer once screens exist, and a client seeing a real interface for the first time notices things no document surfaced. What separates healthy change from creep is bookkeeping — a change that is written down, priced and scheduled is a decision, while the same change absorbed quietly to keep a meeting pleasant is a cost someone pays later in overtime, quality or goodwill.
The mechanisms that hold it in check are unglamorous. A written baseline both sides can point to. A standing list for good ideas that are not in this release, so a suggestion can be welcomed without being started. And the habit of attaching time and money to each addition at the moment it is raised, while the trade-off against the launch date is still easy to weigh.
Common questions
Is scope creep always the client’s fault?
No. It is as often caused by a vague initial scope, an estimate given before the requirements were understood, or a team that says yes in the room and absorbs the extra hours quietly. A specification written as testable statements, plus a change process both sides actually use, protects the schedule regardless of which side a request comes from.
Where this comes up in our work
Related terms
Software Requirements Specification (SRS)
A software requirements specification is the written document defining what a system must do: functional requirements as testable statements, non-functional requirements such as performance and access control, plus constraints and assumptions.
Fixed-Scope vs Time-and-Materials
Fixed-scope and time-and-materials are the two standard ways to price software work.
Discovery Phase
A discovery phase is a short, paid engagement that precedes a build and produces the artefacts a build needs: a written scope, user flows, a technical approach, and an estimate grounded in something other than a guess.
Product Roadmap
A product roadmap is a sequenced plan of what a product will do next and why, grouped by outcome rather than by feature list.
Reading definitions because you are scoping a project? Skip ahead and just ask.