I was talking with a colleague the other day about troubles with scope management in an Agile project. She was lamenting problems that were arising with a particular client who was concerned about the progress of the delivery team. Since Agile teams use time boxed iterations and let scope adjust, this shouldn’t be a problem—should it?
There are a number of issues surrounding scope management in an Agile project, many of them are the same as trying to manage scope in a traditional project:
• Perception versus reality
• Poor definition of how to measure scope
• Running an Agile project in a non-Agile organization
• Wish-based planning
Agile projects, unfortunately, don’t eliminate the perception versus reality problem. Miscommunication and misunderstanding can impact an Agile project even as teams try to expose reality—or at least their reality. Short iterations and working software can reduce the perception/reality gap, but as long as projects are delivered by people and evaluated by other people, a gap will often remain. Good project managers realize they have to manage both—reality and perception.
Another question that isn’t asked or answered very often is—so what is scope? Is it the number of requirements, stories, or features? Is it the total work hours or story points estimated for the project? Is it the documented requirements? At what point is scope determined since in an Agile project features can change over the life of the project? These are all bottom up measures of scope (and therefore progress). Maybe a better approach, particularly in an Agile project in which the detail stories and features are changing, is to ask a top-down question, “Can we deploy this product at the end of this iteration?” Obviously the answer to this question involves some determination about feature completion, but the question really asks about value, about enough value to deploy, not about whether a set of detail requirements have been met.
Scope issues often crop up when Agile teams confront traditional organizational success measurements. The teams view themselves as being successful on the project and managers are wondering what’s going on since they don’t understand this “iterative” approach. This is somewhat different from the perception versus reality issue; it’s more the clash of two different perceptions (or two realities).
Finally, too many organizations subscribe to what I’ve called “wish-based planning.” They do a lousy job of capacity planning, that is, balancing the demands for work to be done with the actual capacity of the organization. These managers don’t understand the difference between stretching limits and being completely unreasonable and stretched project plans become irrational wish-based plans. Agile teams will still experience scope problems in this type of dysfunctional situation.
So, Agile won’t fix all your scope problems. Agile can help teams and management look at scope from a different perspective, but the long-held perceptions of scope will be difficult to change in many organizations.