What causes scope creep?
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 to manage scope creep in agile?
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.
How to manage scope creep in waterfall?
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.
Scope creep FAQ
If you're looking for a quick answers to your questions...
What is scope creep?
Scope creep is the more insidious introduction of new requirements or work incrementally without governance or risk management.
How to manage scope creep in agile?
Agile project processes have inherent controls to manage scope creep given the short increments and regular inspection.
You can avoid scope creep by following agile best practises, ceremonies and disciplines.
It is recommended that the high-level scope for that time box is referenced regularly and any risk of scope creep assessed, potentially found in the sprint backlog, release plan or roadmap.
How to avoid scope creep?
To avoid scope creep it’s recommended to:
- follow best agile practises
- shorter the period between requirements, development and testing
- create a short review cycle or do iterative inspections
- set a clear goals for your sprint/iteration
- put in place regular grooming meetings