Scope creep
skohp kreep
The gradual, uncontrolled expansion of a project's requirements beyond the original plan.
Scope creep is what happens when a project keeps getting bigger without anyone formally deciding to make it bigger. It starts with "can we also add..." and ends with a project that is six months late and three times its original size. The individual additions seem small and reasonable. The cumulative effect is devastating.
It happens because stakeholders see an opportunity ("since we are already building the settings page, can we add user preferences too?"), because engineers want to do things right ("we should refactor the auth module while we are in there"), or because nobody defined the scope clearly in the first place. The most dangerous form is when the scope grows through casual conversations and Slack messages that never make it into the project plan.
The antidote is a clear scope document with explicit boundaries. Not just what you will build, but what you will not build. Amazon uses a technique where the project document starts with a press release for the feature. If the addition would not change the press release, it is scope creep and goes into the next sprint or roadmap item.
Examples
A simple feature request grows into a platform project.
The original ticket says 'add export to CSV.' During planning, someone adds Excel support. Then PDF. Then scheduled exports. Then export templates. Then an export API for third-party tools. The two-day feature becomes a six-week project. The team ships a basic CSV export in two days and creates a separate project for the export platform.
A redesign project loses its boundaries.
The project is 'redesign the dashboard.' By sprint three, the team is also redesigning navigation, adding a dark mode, rebuilding the notification system, and migrating to a new component library. The original dashboard redesign has not shipped. The PM freezes scope, ships the dashboard redesign, and creates separate projects for everything else.
An infrastructure migration absorbs unrelated work.
The team is migrating from AWS to GCP. An engineer suggests adding Kubernetes while they are at it. Another wants to implement a new logging pipeline. A third wants to adopt a service mesh. Each addition is valuable on its own. Together, they turn a three-month migration into an eight-month transformation. The CTO mandates: migrate first, optimize later.
In practice
Read more on the blog
Frequently asked questions
How do you prevent scope creep without being rigid?
Document the scope explicitly, including what is out of scope. When new requests come in, evaluate them against the original goals. If the request is valuable, add it to the backlog for the next phase rather than the current one. The key is not saying no. It is saying 'yes, but not in this release.' Keep a parking lot list for good ideas that do not belong in the current scope.
Is scope creep always bad?
Not always. Sometimes you discover during development that the original scope missed something critical. If you are building a payment form and realize you forgot error handling for declined cards, that is not scope creep. That is an oversight. The distinction is: does this addition serve the original goal, or is it a new goal? Additions that serve the original goal are corrections. Additions that introduce new goals are scope creep.
Related terms
A fixed time period (usually 1-2 weeks) in which a team commits to completing specific work.
The prioritized list of all planned work that a team has not yet started.
The amount of work a team completes per sprint, measured in story points or similar units.
A Request for Comments document that proposes a technical change and invites structured feedback from the team.
A technical document that describes how a system or feature will be built before implementation begins.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.