Scope does not just refer to the definition of the final product but also includes the work required to create it. Scope management, just like it sounds involves deciding what work goes into a project, making sure everyone is on the same page about what and how the product will be produced, and controlling said work as the project progresses. [1]
How does project scope management look different for Agile projects? Traditional and agile project scope management do have some fundamental differences but also share a good deal in common.
Differences In Agile and Traditional Scope Management
In traditional project scope management, you as the project manager were in charge of defining and enforcing the project scope. However, a core part of Agile is the involvement of the product owner in the development process and this means they play a significant role in scope definition for an Agile project. [2]
Instead of trying to fully define scope at the start of the project, in Agile project scope management, the product owner determines high level requirements and the more detailed requirements for what is being implemented in the near future while everything else is left to be developed later on in development. [2]
The rigid nature traditional project scope management and large upfront planning costs cause scope changes to be viewed as problems to be avoided. Whereas Agile project scope management, embraces the Agile motto and welcomes change, viewing it as a chance to improve the product.
Difference in How Agile and Traditional Methodologies Think About Projects
Agile project scope management handles scope changes in a fundamentally different way than traditional project scope management due to the fact that they view projects and project scope in very different ways. In order to keep a project’s scope fixed, either the resources or the time must be somewhat variable since projects hardly ever go exactly as planned. A common visualization of this is called the Iron Triangle where scope is fixed while resources and time are estimated. This has also been adapted to Agile where time and resources are fixed while scope is the estimated parameter [3].
In other words, traditional project management methodologies approach thinking about projects as “how to get X done with the most efficient use of resources and time” and Agile project management methodologies approach thinking about them as “given Y time and Z resources how do we produce the best product with scope X” [3].
Source: created by LK Stewart
Agile Project Scope Management in Practice
It’s great to talk about how Agile handles project scope management differently than traditional methodologies but what might Agile project scope management actually look like in practice?
Initial Planning
Agile may embrace change and not planning details too far ahead but that go with the flow attitude does not extend to jumping into projects blindly and hoping for the best. At the start of the project, you, your team, and ideally the product owner needs to define and set up the product backlog.
The product backlog should be a prioritized list outlining all the requirements of your project. This will act as your project scope and be the backbone that keeps your project from collapsing like a Jenga tower of conflicting requirements, disorganization, and missed deadlines. However, since this is agile, think of it as a bendy backbone that will be reshaped throughout the life of your project [4] [5].
Unlike traditional scope management where the scope is very well defined at the start of the project in Agile the project backlog should be a high-level outline only. It’s there to provide a loose framework for the development schedule and help estimate time and cost requirements. detailed requirements for backlog items should be collected in a requirements document but according to the Agile Alliance a backlog item “only needs to be fully described when a team is about to start work on it.” [4].
The details of project planning and setting up sprints are a topic for another post so let’s skip ahead to the next part of Agile project scope management.
Sprints and Agile Scope Management
At the end of each sprint the product backlog will be reviewed and adjusted as necessary. You can think of the initial project planning and setup and sprint 0. The backlog items are reviewed and decisions are made about which items to keep, which to remove, and any additional items, such as new features or changes requested by the product owner, are added to the backlog [4] [5].
Things are added to the project backlog as they appear so a part of this review also involves organizing and prioritizing items and deciding which should be included in the next sprint [5].
Scope Creep in Agile Scope Management
Neither traditional or Agile projects are immune to scope creep. The less defined more flexible scope, Agile’s iterative development, and the constantly changing product backlog can easily create a prime habitat for scope creep thrive. Thorough backlog reviews are essential in avoiding this and some ruthless pruning of the backlog may be necessary. The inclusion and evolution of higher priority backlog items may mean having to remove other lower priority items in order ensure the project stays within the boundaries of its timeline and budge [2].
Traditional and Agile project scope management may have some fundamental differences but good project scope management is critical to the success of the project in both methodologies.
Sources
Comments