Scope creep is the uncontrolled growth of a project’s scope after work has started. New features, requirements, and “small additions” accumulate, but the schedule, budget, and staffing are not adjusted to match. The result is a familiar failure mode: software that ships late, costs more than planned, or never reaches a stable finish line.
The discipline that guards against this comes from project and requirements management. The IEEE Computer Society’s Guide to the Software Engineering Body of Knowledge (SWEBOK) covers Software Engineering Management as a knowledge area, including the definition and control of project scope and the management of changes to requirements over a project’s life. Defining scope clearly up front, and controlling how it changes, is precisely the practice that keeps creep in check.
Scope creep is not the same as legitimate change. Requirements genuinely evolve as people learn more, and good processes expect that. The problem is uncontrolled change: additions that bypass any evaluation of their cost and impact. A controlled change request weighs the new work against time and budget; creep skips that step.
Because the additions individually seem reasonable, scope creep is easy to miss until the cumulative effect is large. Practices like explicit change control, prioritized backlogs, and principles such as YAGNI all push back against it by forcing each proposed addition to justify its cost.