In plan-driven projects, the scope is defined at the beginning, and changes are monitored and approved only through a change control board. For these reasons, these projects are focused on managing the traditional triple constraint (scope, budget, and time) in order to reduce and, if possible, avoid scope creep. Alternatively, in Agile we have change-driven projects, which are implemented with no certainty about all the requirements at the beginning of the development cycle, or implemented when working on changing environments. Agile projects allow changes in the requirements based on business priorities and also as the team gains more knowledge about the product it is building. That is why Scrum embraces change.
By contrast, scope creep refers to uncontrolled
changes in project scope. There may be several reasons for it, such as the scope of a project being improperly defined or unapproved, or its having had undocumented changes made. I have read that some people don't think that scope creep applies to Agile projects. Others think scope creep does exist in Agile. What I have experienced is that there is a very thin line between changing requirements versus lack of proper definition of stories and acceptance criteria that can lead to scope creep, even in an Agile environment.
I'll use what happened on one of my software development projects to illustrate my point. At the start of the sprint planning meetings, our product owner (PO) defined the priorities, and the team agreed to take the user stories that they believed could be completed within the sprint. The acceptance criteria were clear. At the end of the sprint, the team was ready to demo the work done. We went through the user stories, reviewing the acceptance criteria and demoing how each criterion worked.
During the sprint review, the PO and other managers in attendance questioned some functionality that was not considered initially -- functionality that indicated changes in two main categories:
- Requirements that can be added to the backlog as new stories
- Requirements that mean rework, or the discard of some stories that were already demoed
What is the proper way to proceed regarding such changes? Scrum embraces change, and that is why one of the objectives of the sprint review is that the PO and stakeholders take a look at the product built during the sprint, and review and adapt based on the new information. So, from an Agile perspective, one can consider the new requirements that can be added to the backlog as valid new stories, because Scrum supports experimental product development based on adaptation. But is it acceptable that all the new requirements require rework or the discard of stories already completed? In my view, if those changes are part of the new available information about the product, then they are valid. But if the change is due to a lack of definition of the acceptance criteria, a misunderstanding of the requirements, or a communication problem (among other root causes), then it means that Scrum was not properly implemented.
In this example, we identified the cause as poorly defined stories. However, it was not as though the acceptance criteria were not well defined or a requirement was not stated; it was a lack of definition in terms of what the stakeholders thought
they needed versus what they actually
needed. It was an issue related to poor stakeholder engagement and inefficient communication between the team and the PO, as well as between the PO and the stakeholders. All these variables collectively led to an ineffective Scrum implementation. The key point is to identify this kind of situation just in time for course correction. After we concluded that something was not completely right, the whole team focused and worked on the problem. Five sprints later, they were truly performing and delivering a high-quality product that satisfied the PO's and stakeholder's needs.
Of course, Scrum embraces change; that is how Agile works. But we have to keep in mind that there is a thin line between changing and adapting
and scope creep
. Even when we are in Agile environments, a bad implementation of Scrum can lead to delivering a product that never fulfills the stakeholders' needs. All those continuous changes could mean reworking Agile stories and even starting from square one, which, over time, sprint after sprint, may lead to never-ending projects.