Agile Projects are NOT Immune to Scope Creep!

One of the differences of agile practices when compared with waterfall is the incorporation of change as an integral component of the project as opposed to a threat that needs to be tightly managed or ideally eliminated beyond the planning phase.

Agile practices provide this flexibility by fixing other key constraints such as cost or time, and allow for scope change by allowing the project’s customer to modify the content and priority of items in the work backlog at regular intervals.

This differentiator is often communicated as one of the key benefits of agile methods — while true, don’t assume that agile projects aren’t subject to scope creep.
The normal entry point for scope changes on agile projects is at the end of sprints or iterations during the review of the product backlog at which time the customer would add new work items, clarify existing ones and reprioritize the backlog.

However, this is not the only way in which change can be introduced. Project team members could gold plate or even redo their work. The customer or other project stakeholders could also be influencing continuous change to the “what” or the “how” of the deliverables.

If these types of changes are not reflected as new items in the work backlog, the only indicator of the issue might be velocity metrics, which would illustrate that team productivity is dropping and that it would likely take many more iterations to complete the project.

So what are some methods that a project manager could employ to balance stringent scope control with a “free-for-all”?

1. Ensure that high-level iteration planning includes a determination of how many iterations are required to meet the customer’s minimal must-have requirements. Focus the team and customer on achieving this target, and then use remaining iterations as an opportunity to refactor and refine.
2. Work with the customer to develop a performance incentive plan for the team that balances completing work on time and on budget with meeting all of the customer’s requirements.
3. Track iteration velocity and if it drops or is well below expected levels, dedicate sufficient time during the retrospective session at the end of each iteration to help the customer and team members identify likely causes. These reviews could include looking at what was expected to be completed during the past iteration and comparing that to the work items that were actually worked on by team members, and how many of those were redone or significantly modified.

Agile practices are not a panacea, but with planning and careful monitoring it should be possible to “inoculate” your project against the impacts of scope creep!

Don’t forget to leave your comments below.