Scope Issues in an Agile Project

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.



    1. Jan Brnka says:

      thank you for interesting post.
      I work as a head of development team (6 developers, 2 testers). We have 6 internal consultants and 4 sellers. Our product is a customizable “finished” warehouse management system. For us a project means customization (setting up) of the system, integration implementing and sometimes programming of new modules. The standard project takes form 4 – 8 months. There are from 2 to 8 parallel running projects for the team. We sell a “complete solution” for logistic, production … enterprises, that means internal processes knowhow + hw, sw equipment (special warehouse printers, mobile scanners, … and our WMS system).
      I’m trying to propagate and initiate an agile transformation in our company. There are some practices that are already used but mostly only internally (development team vs. internal consultants). Nowadays I identified the main bottleneck of our project deployment process: acceptance criteria of user stories (or activities in iterations), long term project scope planning and agile approach out of our company at all (our project is still a waterfall from customer’s point of view).
      I identified some mistakes in our “agile” approach that you described in your post. Based on this I have some questions:
      1. Enough value to deploy
      a. What is value for the customer? Is it only a happy path?
      b. How to solve situation when there is customer-accepted value of a process to be delivered and new case appear? It is a new user story? It is in the scope or out of the scope?
      2. Lousy job of capacity planning
      a. How to determine a finish date for a new project when different are running?