How can Scope Creep occur?
Scope Creep will often happen because of good intentions such as the desire to appease a stakeholder or where team members take on more work than was agreed. It is hard to see it happening in real time because it can often be masked within expected or routine actions. The idiom of the ‘straw that broke the camel’s back’ is a pretty good analogy given the cumulative effect of small, seemingly routine actions can create a sudden and serious impact (if you have never heard of this idiom and have no idea why a camel is mentioned in a Project Management article look it up on Wikipedia).
Examples of Scope Creep on a Project
- A new User Story or requirement added to a Sprint or Project after development has started – perhaps one or two could be manageable but if the discipline to remain within existing constraints is not followed the original objective could not be met given the new and unplanned workload
- Gold-plating which occurs when a project team decides that the stakeholder or Product Owner requirements are not sufficient and develops new features or enhancements without being asked. It seems like a really nice thing to do but unless the project has that capacity available and the stakeholder has agreed to it, it can mean the intended value is not what is accepted and realised.
How can scope creep be controlled?
Agile project processes have inherent controls to manage scope creep given the short increments and regular inspection. Therefore, for Agile project teams it is simply a matter of adhering to ceremonies and disciplines for the most part however it is recommended that the high level scope for that time box can be referenced regularly and any risk of scope creep assessed (potentially found in the sprint backlog, release plan or roadmap).
In waterfall, given the longer periods of time between requirements, development and testing, it is recommended to follow Agile principles of short cycle or more iterative inspection and embed these as part of the project quality assurance regime. Documents showing how the original understanding of high-level requirements can be traced through detailed requirements, development and testing can also be used to monitor variation and triage it through governance.
In summary, scope change is not always a bad thing and is encouraged on certain projects such as Agile however needs to be visible and considered at all times. Creating transparency for key stakeholders and decision makers to assess risk and impacts of changes to the project will support and allow for greater assurance of project outcomes.