How to Measure & Prevent Scope Creep

“Scope creep” – this is a term that people are often scared of. Creep is basically any work that makes its way into the Sprint that was not already agreed on and committed to as part of the Sprint Backlog (the scope of work for the sprint). Yes, it could be a big issue for some development teams. But if managed well, it should not be that big a deal.

Creep could happen for a variety of reasons, including:

• Urgent bug/defect fixes that impact customers
• Changes due to competitive landscape
• Change in prioritization of features
• New features added from customer feedback
• Unclear requirements
• Unexpected complexity discovered during the Sprint

Some of these issues - for example customer related issues or new competitive changes are unavoidable - they impact the business, or customers, or might simply be necessary for the growth of the product. Others, such as those arising due to unclear requirements, are avoidable with better planning.

There will always be a certain amount of scope creep. But the goal should be to ensure that it does not impact the goal of the sprint, and is managed well.

Indicators of Issues Due to Scope Creep

To deal with scope creep, it is first important to understand how much of a problem it is for the team. For this, you should measure metrics such as:

• How much of the work that you have completed was not committed to before starting the Sprint? The percentage of unplanned work vs planned work is the Creep. With the principles of Agile, where the teams should be responsive to change, there will always be some amount of Creep. But in general, the amount of Creep should not exceed 10-20%, otherwise this could be an issue.
• How does the percentage change Sprint over Sprint? Is it consistent, or does it vary? If the percentage of creep remains about the same, it indicates consistency and predictability. You can build this buffer into your estimates while looking at ways to optimize it moving forward. If the amount of creep varies significantly sprint over sprint, this could indicate issues in the planning process.
• Measure the work completed (Creep and Done) versus the Unfinished work. And again, it is important to look at this Sprint over Sprint. If there is a trend that things were left unfinished due to the creep (assuming the creep is at a reasonable, consistent level), then it indicates a capacity issue. However, if the team is able to complete all items including the creep, then it shows excess capacity. In either of these scenarios, you should look into accurate Capacity Planning.
• How much additional time has your team had to put in to meet the Sprint goal? This is important to understand how creep is impacting the health, happiness and often, morale of the team.

Ways to Reduce Creep

Once you have a good sense of the amount of ongoing creep, and whether or not it is an issue for your team, the next step would be to figure out ways to reduce it. A lot of the heartburn can be reduced with proper planning from the PM team.

Grooming the Product Backlog to Understand Prioritization and Details

If there is a culture of frequent change of priorities or unclear/incomplete requirements that are causing the creep, then the PM team should be made aware of the impact it has on the delivery schedule. To help with this, the Product Backlog should be groomed properly.

Product backlogs are the laundry list of items that the PM would like to deliver in the Product. The best practice is to break it down into Epics, and User Stories, and then further into work items. Each of these items should be prioritized. For each iteration, or sprint, the PM chooses a set of items that need to be completed - this could be based on priority, or grouping to complete certain features or epics. Breaking down the backlog into epics, stories, work items, and assigning priorities and groupings to them is called “grooming” the backlog. 

If the PM does not have a good roadmap or clarity of what needs to be done when, this can cause change in prioritization and scope. It is important that this be measured and eventually fixed. High priority items in particular should always have complete and clear goals and details.

Trade-off/Cost Analysis for Unplanned but Necessary Items

For other urgent requests where Product backlog grooming doesn’t help (e.g. customer escalation), there needs to be discussions on whether that item can be completed in lieu of something else. Once the sprint has started, it is difficult to swap out items, since there may be dependencies and other considerations. However, discussions should be had between the PM and Engineering teams on how to accommodate the change without impacting the goal of the sprint.

Collaboration and open communication plays a huge part in managing the scope creep and the overall success of the sprint. With proper processes and handling, the creep can be managed, preventing it from derailing the sprint.