Change is good


For agile projects, redefining scope isn't such a creepy thing.


Steven Thomas, BBC, London, England

Scope creep: For project managers these can be two very scary words.

From the beginning, project managers are taught the mantra, “On budget, on schedule, on scope.” But challenges such as too much (or not enough) stakeholder involvement and poor project control can thwart even the best-laid project plans. That push outside the defined scope often leads to more frightening words, such as over budget, off schedule and, in extreme cases, even project failure.

Is scope creep truly as evil as it's perceived to be? For project managers working with the agile methodology, the answer, more often than not, turns out to be “No.”

“All projects experience changing requirements,” says Steven Thomas, senior technical manager at the BBC, a public-service broadcasting company in London, England. “Traditional projects view this as bad. Agile projects embrace it.”

The difference is all in the approach.


The agile approach is iterative. Once a particular part of the project has been implemented, the result is reviewed, and the next move—an iteration, or “sprint,” as it's called in the popular agile methodology known as scrum—is decided. That could mean a revision of what was already completed or something entirely new.

“Agile iterations, therefore, have fixed scope, and the client agrees not to change the scope during the iteration,” says Dennis Comninos, cofounder and managing director of the business and management consulting firm Quanto Strategies in Centurion, South Africa. This is known as “freezing the requirements” or “scope freeze.”

That change control also means that project managers have to hold effective standup meetings, report the project facts and figures, and react to any changes on a set basis, be it weekly or monthly. Agile project managers must also serve as gatekeepers for the rest of the team, reducing outside hindrances such as additions to work loads. They are also responsible for ensuring that lines of communication remain open between team members and the client, if necessary.

“By the same token, the implementation team agrees to deliver exactly what the iteration requires,” Mr. Comninos adds. “In between iterations, the scope may change—but not during an iteration.”

Scope creep becomes a basis for how the team approaches the project, offering three key opportunities for the project team, including:

image Agile project managers must serve as gatekeepers for the rest of the team, reducing outside hindrances such as additions to work loads. They are also responsible for ensuring the lines of communication remain open between team members and the client, if necessary.

  1. Clients can figure out exactly what they want. “In many cases, clients have no idea of what they need at the beginning of a project,” says Jeff Xiong, senior consultant at Thought-Works in Beijing, China, a global IT consultancy that specializes in the application of agile methods for enterprise application integration. “They need to see something working, try it out and then get a deeper understanding about their requirements.”
  2. The project team discovers a thing or two. “Learning during the project is not restricted to the client,” Mr. Thomas says. “The technical team is also discovering what works, and this can have an impact on scope. It's a similar situation for designers if they are doing usability testing. Changing requirements may also reflect changes in the market or legislation, and ignoring these would be foolish.”
  3. Flexibility pays off. “An ability to adjust to change and react to something late in the development cycle is a competitive advantage,” says Dmitri Zimine, senior manager of research and development at virtualization software provider VMware Inc., San Francisco, California, USA.


With every sprint or iteration in agile, you are adding more clarity to the project's scope and reacting to it. But just because you are changing the scope of a project doesn't mean you are adding more to the scope.

“Let's think about a simplified example,” Mr. Xiong says. “At first, you planned to deliver functionality A+B+C+D+E as the deliverable of a project. The client changes the requirement: Now he wants A+E+X+Y+Z. The client does not ask for more deliverables, he just wants to change something— with the total amount of deliverables roughly unchanged.”


We have to stop seeing change as something that must be resisted and limited. Change is the only constant, and agile is a great way of handling it.

—Jeff Smith, Suncorp Business Services, Brisbane, Australia

In traditional methodologies, this scenario would cause scope creep and delay delivery, even if the client isn't getting any extra benefit from the creeping scope, Mr. Xiong adds. In waterfall projects, “we analyze all requirements, we design them all, we code them all, we test them all and we deliver them all—before the client can give any meaningful feedback.”

That's why requirement change becomes scope creep, he says.

So what's a project manager to do?

Gather feedback from the client as quickly and as frequently as possible, Mr. Xiong suggests. To do so, project managers must consistently deliver a running, working system to stakeholders. Quite often, that means agile.

“It's a fundamental change to the production mode: We replace the batch mode to single-item stream,” he says. “It changes the perspective and the relationship. If the client changes some requirements, we just deliver the new requirements and throw out some existing ones. We haven't done anything on them seriously yet. If the client wants more, we simply expand the engagement. Most clients can see the difference.”

With the flexibility agile provides comes a tradeoff, Mr. Zimine warns. “Agile takes away some efficiency.” It can mean more work for the project team. “Every four weeks—or whatever the designated iteration—you have to stop and revisit what you're doing. You don't replan every day, however. It's about finding the right balance between stability and ability to adjust to change.”

It's also important to keep in mind that managing change is only part of what agile accomplishes. Instead of turning to agile as a way to solve your scope creep, determine the root causes of the problem, Mr. Zimine suggests.


Project managers at Suncorp, an insurance and banking business in Brisbane, Australia, use agile methodology, with iterations typically lasting two weeks. Before the start of each iteration, the team meets to discuss the entire backlog of work requests, or stories, including new change requirements, which are evaluated and reprioritized. Changes in scope are monitored continuously.

But it's not the budget, schedule or client desires that drive whether changes in scope are accepted and prioritized for the next iteration.

“People often ask the question, ‘If you keep changing scope, how can you manage cost or time?” says Jeff Smith, CEO of Suncorp Business Services at Suncorp-Metway Ltd. “The answer is simple: Scope change is measured against the business value it will deliver.”

That business value might come in the form of getting software to market faster or tweaking a product based on user feedback. Business value is the difference between the benefit resulting from the change and the cost of making the change, Mr. Smith explains.

If scope creep is such an issue for project managers, it helps to know going in what the primary causes are—and to be on the lookout for them. There are two common instigators, according to Dennis comninos, Quanto Strategies, centurion, South Africa:

1 Stakeholders are only included in the early stages of the project. Stakeholders are asked to accurately specify requirements—even though it may only be later in the process that they come to understand what they really need.
2 Requirements change over the lifespan of a project. Throughout a project life cycle, requirements can change due to learning more about the environmental, social, technological, economical, organizational or political needs of the initiative.

—Steven Thomas, BBC, London, England

“If the business cannot justify the business value of the change, then it does not proceed,” he says. “There is always a budget or a target amount to spend on any initiative. Any change to that has to be constantly prioritized, with only the high business value items getting done within the budget. If more has to be done, the budget increase has to be justified.”


Whether you are working with traditional or agile project management techniques, there's still the chance that scope creep has to be controlled through change management. In the agile world, that means the team is making requirements tradeoffs—swapping out no-longer-needed requirements for new requirements of roughly the same size.

“Embracing change will lead to disaster if uncontrolled,” Mr. Thomas warns. “In agile, the change management decisions should be delegated to the people on the ground—the team, product owner or project manager— unless the project is threatened in terms of cost or time.”

As long as it's kept under control, scope creep doesn't have to instill fear in the hearts of project managers— especially those willing and able to go the agile route.

“We have to stop seeing change as something that must be resisted and limited,” Mr. Smith says. “Change is the only constant, and agile is a great way of handling it.” PM


image Discuss this and other issues in the PMI Agile Community of Practice at




Related Content

  • Goodbye, scope creep--hello, agile! member content open

    By Sliger, Michele Project managers have long attempted to develop processes and policies for effectively managing project scope. Most of these remedies, however, only obstructed the process of developing the best…