Managing Scope Creep: Why, When, and How

All software projects must manage changes to avoid runaway scope creep that threatens success. Here are some effective suggestions.

Karl Wiegers

--

A graphic that says “Beware Scope Creep!”
Graphic by Author

Requirements will change and grow over the course of any project. This is a natural aspect of software development. The project manager must anticipate and plan for growth, such as by incorporating contingency buffers into plans when making commitments. Scope creep (also known as feature creep and requirements creep), however, refers to the uncontrolled growth of features that the team attempts to stuff into an already-full project box. It doesn’t all fit.

Ongoing requirements churn and expansion make it difficult to deliver the top-priority functionality on schedule. This demand for ever-increasing functionality leads to delays, quality problems, and misdirected energy. Scope creep is one of the most pervasive problems in software development.

Defining Scope

The first step in controlling scope creep is to document a clearly stated — and agreed to — scope for the project. Without such a scope definition, how can you even tell you’re experiencing scope creep? The techniques described in my article “Defining Project Scope” provide several techniques for defining a project’s scope. Agile projects should write a brief scope statement for every iteration to make sure everyone understands what will and will not be implemented during that iteration. Alternatively, give each iteration a concise name that conveys the goal of the iteration.

The Vision and Scope Document template that I recommend includes a section called Limitations and Exclusions. Here you could list any product capabilities or characteristics a stakeholder might expect but which deliberately are not planned for inclusion in the product or in a specific release. You might also list items that were cut from the scope, so the scope decision is not forgotten. Itemizing known limitations like this helps the team to make quick decisions if a change request comes in for some capability that’s on the exclusion list.

Does It Belong?

The second step for managing scope creep is to ask “Is this in scope?” whenever someone…

--

--

Karl Wiegers

Author of 14 books, mostly on software. PhD in organic chemistry. Guitars, wine, and military history fill the voids. karlwiegers.com and processimpact.com