Delivery Scope in Agile Vs. Traditional projects | David Tzemach

This article describes the difference between traditional and Agile projects from a scope perspective.

The scope comprises what should be delivered and how much effort is required to deliver it. What + how = project scope. Let’s say that your project is to deliver a three-layer chocolate cake. In this case, the "what" refers to the chocolate cake, and the “how” refers to the effort to prepare the cake. The scope is a key constraint regardless of the project development approach.

Project Scope in Traditional Working Environments

A traditional project is governed by three main aspects: scope, schedule, and budget, also known as the triple constraint triangle. Each corner reflects one part of the project.

However, at the same time, there is a direct correlation between them. Change in one aspect will affect the other two. For example, if the project schedule is changed, the organization will have to adjust the scope of deliverables and the budget to meet the customer requirement. In traditional projects, one often hears, "If it's not in the scope, it’s not in the project." The organization will often define the scope at the start of the project before other aspects such as the schedule and the budget (which often go together).

Let's say that the customer wants to add new functionality. In a traditional project, the scope, schedule, and budget are already contractually determined, making it almost impossible for the customer to adjust the requirements. Therefore, any change requires an issued, planned, negotiated, and signed change request.

Project Scope in an Agile Environment

In traditional development projects, the scope is determined at the start of the project and is not expected to change (Although it may happen in large or complex projects). In Agile development, however, the project scope will most likely change numerous times during the project’s life span, and that's fine.

These changes are welcome because they help us guarantee the customer receives the most suitable product that meets his needs (within the boundaries and limitations set by the organization). Responsiveness to change also ensures the company maintains its competitive advantage. In theory, the scope is viewed as just another variable that comes after the organization has determined the costs and schedule (based on the customer’s needs) at the beginning of the project. The customer’s needs determine the project timeframe and how much he is willing to pay.

Once the team knows the budget and expected timeframe for delivery, it can then translate the customer’s functional and nonfunctional requirements into product backlog items such as featuresdelivery priority, epics, and stories. The project scope is determined when the Product Owner starts adding items to the product backlog and defines the importance of delivery.

In an Agile project, the scope is not fixed but flexible to allow the customer to modify the preliminary requirements and for the Product Owner to re-prioritize the product backlog. This allows the delivery to meet the customer’s needs and expectations. The timelines and budget are still kept, as they were determined at the beginning of the project. There is no release date for the completed scope (depending on the project and customer). Instead, the customer receives product features they pay for based on the priority set by the Product Owner and based on his expectations.