Traditional project management treats changing requirements as a sign of failure in upfront planning. Agile projects, however, have variable scope so that project teams can immediately and incrementally incorporate learning and feedback, and ultimately create better products. The signers of the Agile Manifesto recognized that scope change is natural and beneficial. Agile approaches specifically embrace change and use it to make better-informed decisions and more useful products.
If you run an agile project and your requirements don’t change because you learned nothing along the way, that is a failure. Your product backlog should change often as you learn from stakeholder and customer feedback. It's unlikely that you knew everything at the beginning of the project.
The Agile Manifesto and the principles answer the question, “How agile are we?” The degree to which your project approach supports the manifesto and the principles helps determine how agile your methods are.
The agile principles that relate the most to scope management follow:(1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
(2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
(3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
(10) Simplicity — the art of maximizing the amount of work not done — is essential.
Agile approaches to scope management are fundamentally different than traditional methods for scope management. Consider the differences you see below.| Scope Management with Traditional Approaches | Scope Management with Agile Approaches |
| Project teams attempt to identify and document complete scope at the beginning of the project, when the teams are the least informed about the product. | The product owner gathers high-level requirements at the beginning of the project, breaking down and further detailing requirements that are going to be implemented in the immediate future. Requirements are gathered and refined throughout the project as the team’s knowledge of customer needs and project realities grows. |
| Organizations view scope change after the requirements phase is complete as negative. | Organizations view change as a positive way to improve a product as the project progresses. Changes late in the project, when you know the most about the product, are often the most valuable changes. |
| Project managers rigidly control and discourage changes after stakeholders sign off on requirements. | Change management is an inherent part of agile processes. You assess scope and have an opportunity to include new requirements with every sprint. The product owner determines the value and priority of new requirements and adds those requirements to the product backlog. |
| The cost of change increases over time, while the ability to make changes decreases. | You fix resources and schedule initially. New features with high priority don’t necessarily cause budget or schedule slip; they simply push out the lowest-priority features. Iterative development allows for changes with each new sprint. |
| Projects often include scope bloat, unnecessary product features included out of fear of mid-project change. | The scrum team determines scope by considering which features directly support the product vision, the release goal, and the sprint goal. The development team creates the most valuable features first to guarantee their inclusion and to ship those features as soon as possible. Less valuable features might never be created, which may be acceptable to the business and the customer after they have the highest-value features. |
Traditional project management has a term to describe requirements that change after the project's initial definition phase: scope creep. Waterfall doesn't have a positive way to incorporate changes mid-project, so scope changes often cause large problems with a waterfall project's schedule and budget. Mention “scope creep” to a seasoned project manager, and you might even see him or her shudder.
During sprint planning at the beginning of each sprint, the scrum team can use the product backlog priority to help decide whether a new requirement should be part of the sprint. Lower-priority requirements stay in the product backlog for future consideration.