What is scope creep?
Scope creep has many names. It is also referred to a feature creep, requirement creep, kitchen sink syndrome, and of course, “the devil.” The Project Management Institute defines scope creep as “adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval.”
Implicit in the definition is that in order to have scope creep, a project has to have a scope (“features and functionality”) to begin with. There are any number of great ways to understand project and feature scope, but for simplicity, let’s use the classic Project Management Triangle of Expectations:
Basically, any project can be fast, good, or cheap: Pick two!
When you have agreed with a client about the Quality, Money, and Time parameters for producing a specific set of features, you have a “scope.” Scope creep happens when a change occurs in any of those areas, or someone attempts to cheat and “pick three” at some point during production.
In services, there are other flavors of scope creep.
Scope creep in Agile
Novice practitioners of Agile development sometimes claim that scope creep doesn’t happen in Agile. It most certainly does! While Agile accommodates changes mid-project, those changes have to be carefully managed. In Agile, scope creep usually happens when the product owner refuses to prioritize the user stories against a cohesive vision, creating bloat every two weeks. The scrum master is often complicit in such shenanigans.
Scope creep in project management
The majority of this article assumes that the type of scope creep we are referring to is happening in a service environment and therefore involves project management to some degree. That said, scope creep within project management can be loosely defined as: The result of a project manager who tasks a team with requests outside of the scope, regardless of the source of those tasks. In other words, a project manager who refuses to say No is the one causing the most scope creep.