Agile Scope Creep with Examples

Agile Scope Creep describes how a project’s requirements tend to grow over time, goals, or vision changes beyond what was originally agreed upon. Scope creep is frequently caused by changes in project requirements from key stakeholders (not properly defined requirements and additional features are added to an existing product), as well as internal miscommunication and conflicts.

Remember It is not Agile Scope Creep if you are changing something before the team has started to think about the details or if it doesn’t create additional work for anyone. So use just-in-time planning- have a clear iteration plan with high-level requirements. Work out the details of the iteration just before the iteration is started.

So, in order to prevent Agile Scope Creep, you first need a clearly defined project scope. In order to identify and establish your project scope, follow these five steps:

Start with the “why.” Why are you and your team working on this project? What do you hope to accomplish? Knowing the size and scope of what you intend to achieve will help you define your project scope.
Bring in your project objectives. Your project objectives and project scope are tightly linked. Your project objectives define the aim of your project, and they, in turn, have to fit within your project scope.
Write down your project scope. Remember, this doesn’t have to be very long. Your project scope is just a place for you to clearly outline your project deliverables and how they relate to your project objectives. Feel free to use bullet points, too.
Review your project scope. Make sure you get buy-in from stakeholders, and that everyone is aligned on the project deliverables, objective, and scope.
Make adjustments if necessary. If you weren’t aligned in step four, take some time to rewrite your project scope. Before finalizing it, surface the document to your stakeholders again, to ensure buy-in.

Here are a few examples:

Project stakeholders want to prioritize different features.
Managers or senior team members want to keep clients happy.
Not properly defined requirements and additional features are added to an existing product.
Not a clear product vision for stakeholders.
Items in the backlog are not assigned accurate priority levels.
Items in the backlog lack clarity and depth despite being high priority.
Teams are pushed into an iteration (or sprint) without clear goals.
Changes are introduced or forced into the middle of an iteration.
New features are rushed into development without proper requirement or cost analysis.

Let’s take few examples of poor communication or miscommunication

Your team has been approached by the client and asked to make a ‘few’ changes to the scope without you knowing it.
You’ve failed to communicate project requirements to the team and thus let the project slide in the unknown direction.

There are few a points to consider to prevent scope creep:

Project requirements must be clearly defined in Product Backlog & Sprint Backlog must be thoroughly checked.
Monitoring of project’s progress must be regularly monitored.
Keeping track of the project’s progress and establishing a baseline scope
Using variance analysis to compare actual work performance metrics to the baseline scope, i.e., “How different is the present project from the initial plan?”
Identifying the source and severity of the observed changes.
Choosing whether corrective or preventive action is required in response to change requests.
Using the Perform Integrated Change Control procedure, manage all change requests and recommended actions (whether corrective or preventive).

Example: Sprint backlog change leads to scope creep and how to manage those.

Situation: A critical new item is added to the product backlog which impacts most of the items present in the current sprint backlog.

Solution: Handle these by taking out other not started items of equal size.

Situation: The team learns something new about one of the items in our sprint backlog which impacts heavily the current item.

Solution: Unless significant, handle these within the sprint; that’s why we don’t overcommit in our sprint backlog.

Situation: An item in the current sprint fails an acceptance test and product owner/stakeholders rejected the item.

Solution: Not really a scope change, but can look like new scope if it leads to new items being added to the product backlog, and definitely something we should handle within the sprint.

Situation: We’ve got less (or more) capacity than we expected at the beginning of the sprint.

Solution: If capacity is more than expected, consult with the product owner and add a small item that you can get done in the remainder of the sprint. If capacity is less than expected, consult with the product owner and remove items from the sprint if necessary.

Situation: The product owner has changed priorities in the middle of the sprint or cancels the sprint.

Solution: Coach your product owner and stakeholders that agility requires stability for a week or two, but if absolutely necessary then only change priorities of the items selected for the sprint and if the sprint goal is obsolete then only cancel the sprint.

Situation: Sometimes too many stakeholders with different priorities lead to scope creep.

Solution: Implement RACI Matrix to support stakeholder management.

Responsible. This is the person who is driving the project. They’ll make most of the on-the-ground decisions.

Approver. Sometimes, you may need approval from a stakeholder or group of stakeholders. Your Approvers might set the budget, objectives, or tone, to name a few examples.

Consulted. Consulted stakeholders are people you might check in with to get their opinion, insight, or guidance. Though the Responsible & Approver roles have the final say, the Consulted role is usually an expert in the field.

Informed. This is anyone who needs to know about your project. The Informed role might include your project team, cross-functional stakeholders, or executive leaders.

If you prevent scope creep from happening in the project how can you say that the project is Agile? Because agile is all about making changes to the project in an efficient way?

In an agile framework, scope creep is really a problem caused by injecting new or unplanned work into the middle of an iteration, rather than adding scope to the overall project. All agile frameworks solve this through formal processes and ceremonies. In Scrum, for example:

New work should generally only be introduced during Sprint Planning.
New work that takes priority over current work required early termination of the current Sprint, and a return to Sprint Planning.
New work for the project must be prioritized by the Product Owner in collaboration with the stakeholders, so scope creep at the project level is managed through consensus that the proposed work is relevant to the project’s goals.
In Scrum, iterations are a a fixed time-box with a relatively fixed cost (excluding capital costs), but scope is a variable constraint.
“Scope creep” in the traditional business sense of the term will extend the total run-time of the project. By adding scope to the project, you impact the schedule (generally making it longer). You manage this through transparency and effective communications with stakeholders.

Kanban and Lean have similar mechanisms for managing change. The point is that there’s no free lunch. Adding scope adds cost or time to the project. You can’t fix cost, schedule, and scope at the same time, so the increased scope will generally increase a project’s costs and schedule as well, while often reducing overall quality as the organization attempts to increase scope without increasing costs or extending the schedule. As a Scrum Master, you need to be able to articulate the trade-offs for the project.

PMI Agile Blog on Scope Creep: Click Here