Get certified - Transform your world of work today

Close

The Thin Line Between Changing and Adapting and Scope Creep

20 October 2015


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:
  1. Requirements that can be added to the backlog as new stories
  2. 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.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.3 (3 ratings)

Comments

Tim Baffa, CSM, 10/20/2015 9:30:35 AM
From the example you provided, I would not conclude that Scrum was poorly implemented.

Yes, it seems the team completed stories that the business did not really want in hindsight, but that feedback loop and re-evaluation of product vision is also present in healthy scrum adoptions. Just because the first sprint created a number of non-value stories, it resulted in additional discussion between the team and PO/stakeholders to not only identify impediments (poor grooming, poor product vision), but also to create new stories that truly reflected business value and product vision.

A popular tenet of Scrum is to "fail fast", and that seems to be what happened here. You should view that first sprint as a rousing success, because it quickly exposed issues and led to their resolution.

Your situation occurred with a poor product vision, but it could have also occurred with a very clear product vision, followed by an "aha" moment in the sprint review that revealed a new product vision and a subsequent scrapping of the first sprint's work product. This is a GOOD thing, and reflects a mature agile mindset.

Ultimately, the PO is responsible for directing the work to the team, and it is upon the PO to ensure that the team is always working on items that have the highest business value.
Haim Arazy, CSM, 10/20/2015 9:04:17 PM
Let's look at the bright side: by implementing Scrum the damage was limited to a single sprint.

The PO has to keep his end of the bargain and do his homework well ahead of time. But... no one's perfect, such situations are bound to happen every once in a while.
Leonel Zapien Lopez, CSM, 10/21/2015 12:26:15 AM
Thanks for your feedback. I just would like to add that this kind of situation was the usual behavior of this project sprints after sprint... changing again and again over the time. It was not an isolated one-time event. But as you said, by implementing Scrum the damage was limited, after the team learned and was able to grow and perform.
Jim Pahl-Washa, CSP,CSM,CSPO, 10/21/2015 10:58:43 AM
It's been my experience that PO's are quite often caught in the middle of competing forces, each having their own vision. In our case, we have Subject Matter Experts (SME's) applying pressure on our Product Owner, when they're fully aware that their respective priorities don't synch with the overall vision or at least the previously agreed upon timeline. This is dangerous and dysfunctional territory that has to managed carefully.
Alpesh Shah, CSM, 10/28/2015 6:14:22 PM
Scope creep in project management refers to uncontrolled changes or continuous growth in a project’s scope. This can occur when the scope of a project is not properly defined, or documented.

The longer the delivery cycle the more likely additional requirements or changes to existing requirements will occur.

In agile, change is an accepted part of software development, and there are stopping points built in to the project to enable the team to address these change requests. At the end of iteration, the team reviews the work done on the product, the process it followed to get there, and the changes that it may have to make to better accommodate the needs of the customer or changes in the domain. This is the opportunity for the customer to make changes in the backlog, and based on priority, the team will work the next set of features in the next iteration.

Fail Fast Means Learn Fast however, the customer should realize that playing with the product would not get the team any closer to a fully functional release. That is why it is important to always have the release plan highly visible and revisit it at the end of iteration—to remind everyone of the ultimate goal.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe