In this lesson, we will walk through the Develop Scope Structure process.
Develop Scope Structure is where we take the defined project scope and organize it into a structured map of all the work. The classic outputs here are the Work Breakdown Structure, the WBS dictionary, and the overall scope baseline. In adaptive approaches, this same idea shows up as user stories and a product backlog. All of these outputs serve the same purpose: they turn abstract scope into a concrete, organized representation of the work we must deliver.
Let’s start with the core output: the Work Breakdown Structure, or WBS.
The WBS is a hierarchical decomposition of the total project work. It shows the project broken into deliverables and then into smaller work packages. The WBS is powerful because it gives everyone a single visual picture of all the work required to deliver the scope. It makes planning, estimating, assigning responsibilities, tracking progress, and managing changes much easier. Without a WBS, work tends to be missed, double‑counted, or managed in an uncoordinated way.
To build a meaningful WBS, one of the most important inputs is the project scope statement. The scope statement tells us what the project and product scope include, what the key deliverables are, and where the boundaries sit. It also lists assumptions and constraints that shape how we can decompose the work. We use the scope statement as our primary source for “what” needs to be in the WBS. If a deliverable is not in the scope statement, it usually should not appear in the WBS.
Requirements documentation is another critical project document for creating the WBS. While the scope statement focuses on major deliverables and boundaries, requirements documentation captures detailed functional and nonfunctional needs. When we develop the WBS, this detail helps ensure that all necessary work is represented. It reduces the risk that a requirement is forgotten or that an important piece of work is left out of the structure.
On the project management plan side, the scope management plan guides how we create and maintain the WBS. It often defines the level of detail we should decompose to, the coding structure, and who participates in developing and approving the WBS. This keeps the WBS consistent with organizational standards and makes it easier to integrate with other systems, such as scheduling and cost control tools.
Now, how do we transform these inputs into the WBS? We rely on a few key tools and techniques.
Expert judgment is very important. We need people who understand the project’s domain, the technology, the delivery approach, and the organization’s way of working. These experts help identify all the necessary work, judge how far to decompose, and ensure that the WBS reflects reality rather than theory. Their input reduces the risk of missing major components or over‑engineering the structure.
Brainstorming is also useful in developing the WBS. By bringing the team and key stakeholders together, we can generate a comprehensive list of deliverables and work items. Brainstorming helps uncover work that individual team members might overlook. In practice, we may start with the major deliverables from the scope statement and then brainstorm lower‑level components until the team agrees the work is fully captured.
Decomposition is the core technique of this process. It is the step‑by‑step breaking down of the project scope into smaller, more manageable pieces. We continue decomposing until each work package is small enough to estimate, schedule, assign to an owner, and control. This level of detail provides clarity for planning and execution. For example, instead of just having “user interface” as a deliverable, decomposition might break it into login screen, dashboard, settings page, and so on, depending on the project.
Next, let’s look at the WBS dictionary, which is closely related to the WBS.
The WBS itself shows the structure, but the WBS dictionary provides detailed information about each WBS element. It typically includes descriptions, assumptions, responsible roles, sometimes estimates, and other relevant details. The WBS dictionary adds clarity and reduces ambiguity. It helps team members understand exactly what is included in each work package and supports consistent assignment, estimation, and control.
Just like the WBS, the WBS dictionary is driven by the project scope statement and requirements documentation. The scope statement sets the overall boundaries, and the requirements fill in the detailed expectations. We again rely on expert judgment and decomposition to define the contents of each WBS element in a way that is precise and usable for planning.
Now let’s talk about the scope baseline, another key output of Develop Scope Structure.
The scope baseline usually includes the approved scope statement, the WBS, and the WBS dictionary, all taken together as a single, formal baseline. Its value is that it becomes the official reference for what is included in the project scope. When change requests arise later, we compare them against this baseline. This helps us manage scope changes in a controlled way, assess impacts on time and cost, and avoid uncontrolled scope creep.
To form a reliable scope baseline, we again depend on the same underlying inputs: the project scope statement, requirements documentation, and any approved changes to scope. Approved changes are especially important because they ensure that the baseline reflects the current authorized scope, not just the original definition. The scope management plan also influences how and when this baseline is formally created and approved.
Now let’s look at how this process works in adaptive or hybrid approaches, where two additional outputs become central: user stories and the product backlog.
User stories are small, user‑focused descriptions of functionality or outcomes. As an output of Develop Scope Structure, they represent a way of structuring scope into items that can be delivered incrementally. Their value is that they are easy to understand, easy to prioritize, and naturally support conversation and clarification. In an adaptive context, instead of a fully detailed WBS at the start, we may express much of the scope as a collection of user stories that are refined over time.
The product backlog is the ordered list of user stories and other work items that represent the planned product scope. As an output of this process, the product backlog serves as a living, structured repository of all known work. It is valuable because it provides a transparent and flexible scope structure that can be reprioritized as we learn more. It supports incremental delivery, continuous refinement of scope, and rapid response to change, while still preserving traceability back to higher‑level objectives and requirements.
Now that we have covered the main outputs, let’s briefly review the remaining inputs and environmental factors that influence how we develop the scope structure.
Approved changes, as mentioned earlier, are essential because any authorized changes to scope must be reflected in the WBS, the WBS dictionary, and the scope baseline. This keeps the scope structure aligned with current decisions and prevents the team from working to outdated definitions.
Enterprise environmental factors also shape how we structure scope. Organizational structure, reporting requirements, existing IT tools, and governance frameworks can influence how we format the WBS and how detailed it needs to be. For example, a matrix organization with strong financial controls may require that the WBS align with cost accounts or reporting units.
Organizational process assets, such as WBS templates, examples from previous projects, and decomposition guidelines, provide practical help. They promote consistency across projects, speed up the creation of the WBS, and leverage past learning. Using proven templates reduces the risk of missing typical work elements and makes it easier for stakeholders to understand and navigate the WBS.
To summarize, Develop Scope Structure takes the defined scope and turns it into an organized, manageable representation of the work. In predictive environments, this shows up as the WBS, the WBS dictionary, and the scope baseline. In adaptive environments, it may show up as user stories and a product backlog. The key inputs are the scope statement, requirements documentation, the scope management plan, and any approved changes. With expert judgment, brainstorming, and decomposition, we create a complete, clear, and traceable structure that supports better estimation, planning, execution, and scope control throughout the life of the project.
