"Scope creep" is a term that I see being used by Scrum teams. I've always wondered if this term smells of inadequate Scrum implementation. It's an indication of traditional project management that's disguised in the appearance of Scrum.
To explain, scope creep originated based on the metaphor of the "iron triangle." Because of the rigidness of the triangle, projects respond to scope creep by appropriately increasing budget and/or schedule to address the changes or new requirements. For this reason, there was a change-control process to control scope creep. To further control the change, the responsibility of the project manager was to influence the factors that can cause scope change.
Based on the previous mind-set, organizations delivered on time, within budget, the agreed-on scope — but the wrong product. I would argue that we delivered wrong products while missing all of these three constraints. The cause of having the wrong product is treating scope creep as a threat to avoid, rather than as an opportunity for creating the right product.
Please allow me to be radical: If the customer does not change his mind based on what we deliver every sprint, then the Scrum team might not be addressing opportunity areas. The value of customer feedback is not just for the team but, much more important, for the customer to change his mind. Changing the customer's mind is the opportunity we seek in our discovery journey. This is because Scrum is meant to support the experimental product development that's required to discover what is right for the customer. Up front, the customer might have a vision of the product, but he has to discover the product. Meaning: Producing according to the customer's preassumptions of what the product looks like reflects that we, as a Scrum team, did not generate knowledge for the customer to learn about his product.
In my view, scope creep is a legacy inherited by Scrum teams from organizational project management processes. Those processes were, in reality, based on industry-neutral practices that at best are not effective for software development.
But if the Scrum team is continuously grooming the backlog and acting on customer feedback, why do we still use the term scope creep? I find three common contributors to the concept of scope creep in Scrum projects:
1. A disconnect between the Scrum team and product owner
The product owner should commit with the team during sprint planning, instead of the team commiting alone. This disconnect encourages the thinking that the team is only doing what the customer wants. The feedback given by the product owner at sprint end can be interpreted as "he changed his mind and therefore this is scope creep." Improving the bond between the team and product owner creates an environment for the product owner that gives him the courage to say, "I'm not sure what I want." This is what Scrum was meant to address: experimenting to discover the product through the process of the customer learning in addition to the team.
2. Project governance
Enterprise projects, even those that use Scrum, are governed by a project management office that implements industry-neutral processes. These processes can mandate thinking in terms of milestones, fixed scope, controlled budget, change requests, and so on. None of these practices talk about "experimentation," "product discovery," "value generation," or other Scrum concepts. These Scrum concepts cannot be aligned with or mapped to the terms of project governance.
3. The team's instability
Enterprise IT projects, in my experience, rely mostly on contracted teams. Neither the contracting relationship with the vendor nor the lack of team stability promote instilling Scrum values. Such values are the foundation for embracing experimental delivery and the mind-set of product discovery. Companies, however, want to establish a fixed budget for the contractors. For me this acceptable, but the problem is that these companies usually want to have fixed scope to ensure an acceptable ROI. The scope creep mind-set can find lot of support in such setups. In short, it is an evil to avoid.
To summarize, the term "scope creep" is an indication of ineffective Scrum implementation. The iron triangle metaphor that gave rise to this term should not be promoted when managing Agile projects. There are three factors to watch for — a disconnect between the Scrum team and the product owner, project governance, and an unstable team — because they cause the prevalence of the concept of scope creep among Scrum teams.