Definition
Scope Creep
Scope creep is the gradual, uncontrolled expansion of a project's requirements after work has begun — small additions and 'while we're at it' requests that accumulate until the original plan no longer fits the time or budget. It is a leading cause of missed deadlines, because each addition feels minor but the total quietly overruns the commitment.
Key takeaways
- Scope creep is the gradual, uncontrolled expansion of a project's requirements after work has begun — small additions and 'while we're at it' requests that accumulate until the original plan no longer fits the time or budget. It is a leading cause of missed deadlines, because each addition feels minor but the total quietly overruns the commitment.
- Scope creep rarely arrives as one big decision.
- Mid-cycle, scope creep shows up in the data before it shows up in conversation: a burndown line that ticks upward instead of down means work was added after the commitment.
Scope creep rarely arrives as one big decision. It seeps in through a stream of reasonable-sounding additions: an extra edge case, a nice-to-have toggle, a stakeholder's late request. Each is small enough to wave through without re-planning, which is exactly why the total goes untracked. By the time the cumulative weight is felt, the cycle is half over and the original commitment is no longer achievable.
The antidote is a defined scope and a deliberate gate for changes. When a project starts with explicit requirements and explicit non-goals, any new request can be measured against them: is this in scope, or is it a change that must trade against something else? The point is not to refuse all change — requirements legitimately evolve — but to make adding work a visible, costed decision rather than a silent default.
Mid-cycle, scope creep shows up in the data before it shows up in conversation: a burndown line that ticks upward instead of down means work was added after the commitment. Catching that early lets a team make the trade explicitly — cut something, extend, or accept the slip — rather than discovering at the deadline that the goalposts moved.
Related terms
- Acceptance CriteriaAcceptance criteria are the specific, testable conditions a work item must satisfy to be considered complete and correct. Written before work starts, they define the boundaries of a feature — what it must do, and how you'll know it works — turning a vague request into a checklist everyone agrees on, so 'done' is verifiable rather than a matter of opinion.
- PRD (Product Requirements Document)A PRD (product requirements document) defines what a product or feature should do and why, before it is built. It captures the problem, the target users, the goals and success metrics, the scope, and the requirements — giving design, engineering, and stakeholders one shared reference so everyone builds toward the same outcome rather than their own interpretation.
- BurndownA burndown chart tracks remaining work against time over a cycle, sloping from the total scope down toward zero as items are completed. It shows whether a team is on pace to finish what it committed to, making slippage visible early. The ideal line falls steadily; a flat line warns that work is stalling.
- Sprint PlanningSprint planning is the meeting that opens a sprint, where the team reviews the prioritized backlog and decides what it will commit to in the coming iteration. The team agrees on a sprint goal, pulls a realistic amount of work it believes it can finish, and clarifies scope. The output is a concrete, achievable plan for the time-box ahead.