The argument, for and against, of Scope Creep
I’ve recently been doing some courses to expand my knowledge on Business Analysis recently and one part of the course that stood out to me was the view of scope creep.
In some ways, scope creep can be seen as a good thing. I thought “What? There’s no way that can be right!”
First, let’s ask the question of what is scope creep, anyway?
Well, it’s when deliverables exceed the agreed project scope.
During my time as a software tester for nine years (that’s a long time), scope creep was probably the worst thing that could happen. To be fair, as the software tester, I would be one of the last people involved in the development cycle. So the added stress and frustration didn’t help me. Especially if the deadline didn’t move.
But during the courses I’ve taken I can somewhat see the reasons why scope creep can be a good thing. Let’s take a fair and balanced approach to this (or try to at least).
The argument for Scope Creep
Unlocking new opportunities
Okay, I will say this. If the Scope Creep is necessary, justified and required, then it can unlock new opportunities to enhance what is being delivered.
At the end of the day, the project is something that delivers the product. We want to make sure that right product gets built, right?
Avoids disaster
Sometimes, you need Scope Creep to prevent the project from failing. Something can get missed (I mean, let’s be real, mistakes happen)
Just-in-time requirements
In Business Analysis, there’s an acronym called VUCA. Which stands for; Volatility, Uncertainty, Complexity and Ambiguity. Scope Creep can refer to Volatility (being ready for changing requirements) and Uncertainty (creating just-in-time requirements). It could be argued that Complexity also refers to Scope Creep as that relates to adjusting complexity as we go.
With this mind, Scope Creep is inevitable and could be argued as being welcomed as part of the Business Analysis process.
The argument against Scope Creep
Last minute decisions lead to chaos
I’ve been on sprint teams where scope creep has been brought in at the last minute, and the original deadline is upheld. This leads to people rushing to get the new requirements in, which only leads to defects being introduced.
I’ve seen this happen so many times, and people wonder why introducing new requirements late into the development cycle never seems to work (it’s a real mystery)
Lost confidence in stakeholders
When Scope Creep happens, I’ve seen teams lose confidence and become less trusting in the stakeholders as a result of this. Especially if it happens repeatedly.
Who would want to work with stakeholders if they’re known to introduce requirements late in the development cycle?
How can we prevent Scope Creep?
Preventing Scope Creep shouldn’t sit with development teams, preventing Scope Creep sits with the Business Analyst and stakeholders.
A good way in preventing Scope Creep is creating a good business case. A business case documents benefits and justifies resources. The business case is a good example of a living document, that includes the results of needs assessments and other data, and adjusts over time to align with organisational objectives. A business case also provides valuable information of the business need and the proposed solution.
It could also be argued that requirement elicitation is also important in preventing Scope Creep. This involves the discovery and progressive elaboration of understanding the needs of stakeholders and customers. Elicitation and analysis should be more about dialogue, shared understanding, visuals, and exploring. This will help with engaging with the business in finding the correct requirements (it is important to note that of course, time is limited, and it’s important to prevent analysis paralysis).
Conclusion
I think we can all agree Scope Creep is awful for everyone involved. Nobody wants it. But if there is a justified reason (and it has to be an excellent reason) why there needs to be Scope Creep, then it can be a good thing. If it ensures that the project delivers the right product, then that’s what everyone wants at the end of the day, right?
