Scope is an important concept no matter the type of project you are working on or how you are doing it. Scope is important in traditional methods, waterfall, or Agile. Scope is what all you are delivering at the end of a project while cope management specifically is determining and maintaining what is to be and not to be included in a project. Traditionally, scope management includes 6 processes:
Planning- figuring out how to manage the scope and its requirements.
Collecting- Establishing and documenting the features and functions of a product as well as the process of its creation.
Defining- Reviewing planning and other documents. Additional information might be added and changes might be requested.
Creating WBS- Breaking down deliverables into several smaller and easier parts.
Validating Scope- Deliverables are agreed upon formally, and customers or shareholders might request changes.
Controlling Scope- Managing changes to the scope during the project.
A very common issue with scope management is scope creep, which is where the scope of a project just keeps getting bigger and bigger and eventually collapses because of its own weight.
Something to note is that traditionally, scope management utilizes a WBS or a Work Breakdown Structure. A WBS is a grouping of the work into parts based on how they are performed. A WBS is used to define the total scope of a project, A WBS can be developed in different ways, like mind-mapping or the analogy approach. A WBS is not really used in Agile though and a product backlog is usually used in place of it.
Scope is an extremely important part of a project. Without it, the project itself would not be as defined, it helps you get off on the right foot and maintaining it will help you stay on track when developing your project. Poor management of it however can lead to things like scope creep where a lack of upkeep for the scope can end up causing a project to fail.
As you can see, scope in traditional projects is something that is very strict, rigid, and well-documented, this clashes with the fluid and evolving nature of Agile. In Agile, the product you are delivering evolves after every sprint, and the requirements are liable to do the same. This means that the requirements at the end of a project are probably somewhat removed from the original requirements at the start of a project. A traditional plan-driven scope is reluctant to make changes because it can potentially mess with all the factors that went into the planning. Agile, however, embraces those plans, which is mainly because the plan for the scope is not as set in stone. Think of a traditional approach as studying for a test, and the agile approach is winging said test. That is not to say though that there is a lackluster effort put into the scope when it comes to Agile, the planning is just more flexible. Because of this, an Agile approach is a lot better at adapting to changes made to the scope of the project.
Below is a graphic meant to visualize the Tradition vs. Agile approach.
As you can see, in a traditional method the features of the project are the first thing defined, this helps get a better estimate of the resources and schedule, leading to a better version of scope planning. Agile however, flips the whole thing over, the cost and schedule are the first things decided, making the features more flexible.
We know that Agile is different when compared to the rest, but how does it shape up exactly as a one to one comparison of traditional methods? Below is a list detailing as much.
Scope Planning- As discussed earlier, Agile does not follow a strict plan. Instead, the scope is modified based on present needs at the time.
Scope Definition- In Agile, features are defined in a product backlog. And then the features are placed into the project during its iterations. An iteration can be comparable to a work package in traditional methods. Boundaries, objectives, and the product scope description. Meetings are also much more utilized to accomplish things like roadmaps or milestones or to confirm when something is done.
A work package is the lowest task level of a WBS. It is dependent on a time frame however, a short project can have work packages that encapsulate a week or less, similar to something like Agiles' sprints and deliverables. But it can also represent a month's time of work if the project is a long one.
Scope Verification- In a traditional method, there is usually required documentation of the completion of a product, along with why it was accepted or not. Agile is different as it is more informal, while it is helpful to document that something has been completed, there is no need for formal documentation. An example is when something is finished, a note that represents the objective could be moved from the "working on" to the "completed" side, or there could be formal documentation. The main thing is that it is not as strict about documentation.
Scope Control- Control of the scope in Agile, means managing the product backlog. But once a team has committed to a plan as to what to do for an iteration, the scope during that time is unchangeable during that iteration. Also, Agile plans and product roadmaps are altered to better represent the team's progress.
You can notice that this list is a little shorter than the traditional list. That is because it is missing two steps, the first being collecting requirements and the other being creating a WBS. Agile does not have a WBS step because Agile does not really use WBS. But when it comes to requirements, Agile's in-the-moment modifications to the scope planning make it so there is not really a need for a collecting a requirements phase.
Below is an image that converts the steps of traditional scope management to its Agile equivalent.
As you can see, there are many differences when it comes to scope management between a traditional and Agile approach. But the main thing to take away is that traditional methods are a lot stricter and do not allow as much flexibility as when compared to Agile.