PMP Scope Management: Requirements, Scope Statement, WBS and Backlog

Developing and managing project scope means deciding exactly what the project will and will not deliver, getting the people who matter to agree to it, breaking it into pieces the team can plan and deliver, and then keeping the delivered work inside that agreement. Scope is the boundary everything else is planned against: schedule, cost, resources and quality all depend on it.

The PMP Examination Content Outline lists three enablers for this task, and this lesson follows them:

1. Define scope: collect requirements, then describe the product and the deliverables, how each will be accepted, and what is excluded.
2. Obtain stakeholder agreement on project scope: resolve competing expectations, get the scope approved, and later get each deliverable formally accepted.
3. Break down scope: decompose it into a work breakdown structure (WBS) in predictive work, or a product backlog of epics and user stories in agile work, at a level of detail that fits how well the work is understood.

The task title also says manage: once scope is agreed, it changes only through the agreed route. In a predictive project that route is change control against the scope baseline; in an agile project it is the product owner and the backlog. Hybrid projects use both, component by component.

Two neighbouring tasks are kept separate: deciding which work delivers the most value and when (value-based delivery) and running the formal change control process itself (a Business Environment task). This lesson covers them only where they decide a scope question.

Requirements are collected with whichever elicitation technique suits the stakeholders and the situation; no technique is best everywhere. The deciding question is usually why the current approach is not producing clear requirements: people cannot put the need into words, people disagree, there are too many of them to meet, or time is short.

Two pairs are easy to confuse. Observation versus prototyping: observation reveals how people work today when they cannot explain it; prototyping reveals what they want from the new product when they cannot specify it. Workshop versus separate interviews: interviews collect each group's view in isolation, so conflicting needs stay conflicting; a facilitated workshop puts the groups in one room to reconcile them, which is why it is the usual choice when cross-functional agreement is needed against a deadline.

The results are recorded as requirements documentation and, where traceability matters, in a requirements traceability matrix (covered below). Requirements are not scope until they have been analysed and agreed: some will be deferred, some excluded, and some turned into deliverables.

The project scope statement is the detailed description of the project's scope: the product scope description, the deliverables, the acceptance criteria for those deliverables, and the project exclusions. It is the single document that says what will be delivered, how each deliverable will be accepted and what will not be delivered. Constraints and assumptions that shape the scope are recorded alongside it, usually in the assumption log.

It is often confused with three other planning documents:

A simple test: the charter authorizes, the scope management plan explains the method, requirements documentation captures needs, and the scope statement sets the boundary.

Exclusions versus assumptions

Many scope disputes start with something nobody wrote down. If stakeholders talk as though an item is included, or a document is silent on it, the project manager clarifies it before sign-off and records the outcome explicitly: either as an inclusion (a deliverable) or as an exclusion. Exclusions are as important as deliverables because they stop silent expectations turning into disputes at handover.

The choice between an exclusion and an assumption depends on whether the fact is settled. A point that has been confirmed as outside this project's scope (for example, a landlord confirming that it will carry out the building fit-out under its own contract) is written into the scope statement as an exclusion. A point that is still uncertain but being treated as true for planning goes in the assumption log, where it is monitored; if it could hurt the project, it may also be a risk. Logging a confirmed fact as an assumption leaves it looking negotiable. In agile and hybrid work the same discipline applies to a release: the release agreement names what it does not contain as plainly as what it does, so expectations that belong to later releases are settled before delivery starts.

Acceptance criteria are the measurable conditions a deliverable or user story must meet to be accepted. They are agreed while scope is being defined, not at handover, because a deliverable with no stated criteria invites an argument when the customer sees it. A good criterion can be checked objectively: two people applying it would reach the same verdict. For an online booking form, "a confirmation email is sent within one minute of a completed booking" and "a booking date in the past is rejected with an error message" pass that test; "user-friendly", "fast" or "reliable" do not until they are turned into something measurable.

Acceptance criteria are also different from quality metrics. Quality metrics, defined in the quality management plan, describe how the project measures the quality of its work and processes in general; acceptance criteria are the deliverable-specific conditions the customer will accept that deliverable against, and they live in the scope statement (and, per work package, the WBS dictionary).

Agile teams use three related agreements that the exam expects you to keep apart:

Ready is an entry condition; done is an exit condition. A useful way to tell them apart is to ask what kind of standard is missing. A problem with whether work is clear and understood before it starts is about readiness. A problem with a standard that every piece of work should meet, whatever it does, is about done. A disagreement over what one particular item was supposed to do is about that item's acceptance criteria.

Two other team agreements sit nearby but answer different questions. The iteration goal (in Scrum, the Sprint Goal) is the single objective the current iteration works toward; a work-in-progress (WIP) limit caps how many items can be in progress at once, to keep work flowing. Neither one says when an item is fit to start or when it is finished.

When several teams build one product, a single shared definition of done is needed. The Scrum Guide states that Scrum teams working on the same product must mutually define and comply with the same definition of done. Separate team-level definitions let each team call its part done while the combined product is not. A shared definition puts integration, documentation and other cross-team standards inside every iteration's work, which is what makes each combined increment releasable rather than releasable later.

Stakeholder agreement on scope is obtained by facilitating a shared decision against the project's business objectives, then recording it in an approved form: a signed scope statement and baseline in predictive work, or an agreed release goal and prioritized feature set in agile work.

When stakeholders want different things, the project manager's first move is to facilitate, not to pick a side or escalate. Bring the stakeholders together, make the trade-off visible (what including the item costs in time, money or risk) and test each option against the objectives in the charter and business case. The goal is a decision the stakeholders own and can defend, recorded before sign-off. Escalation to the sponsor is for disagreements that facilitated discussion has not resolved, because the sponsor's role is to settle what the project team cannot.

Agile projects reach agreement at a different grain. Funders and stakeholders still need assurance about what a release will contain, but freezing detailed requirements would defeat the approach. The usual answer is to agree a release goal and a prioritized set of features, with the detail emerging through backlog refinement. That gives funders a commitment at the level they need, outcomes and priorities, while leaving the team room to learn what each feature should look like in detail.

The requirements traceability matrix

A requirements traceability matrix links each requirement to its source (the business objective or stakeholder need behind it), to the deliverable or story that satisfies it and to the test that verifies it. It is different from the requirements management plan, which describes how requirements will be analysed, documented, prioritized and traced; the matrix is where the links themselves are recorded. It answers three kinds of question: is every requirement delivered and tested (audit and regulatory proof), what depends on this feature (impact analysis before cutting or changing it), and does every deliverable trace back to a requirement (a guard against scope creep and gold plating).

In agile work under regulation, traceability is kept as the work is done: each story is linked to its requirement and its tests as it is built. Keeping the matrix current story by story gives an always-current audit trail from requirement to implementation to test, without heavy up-front documentation.

A work breakdown structure is a hierarchical decomposition of the total scope into deliverables, each level more detailed than the one above, down to work packages. A work package is the lowest level of the WBS: small enough that its cost and duration can be reliably estimated, it can be assigned to one owner, and it can be monitored. Decomposition stops there.

Key rules for building a WBS:

• It is deliverable-oriented. WBS elements are nouns, the things the work produces ("roof membrane, installed", "network cabling, certified"). Verb phrases such as "lay membrane" or "run cable tests" are activities; they belong in the schedule, where work packages are broken into activities with durations.
• The 100% rule. The WBS contains all of the work in scope and nothing outside it, and each level's children add up to 100% of their parent. An in-scope deliverable missing from the WBS breaks the rule; so does an element for something the scope statement excludes. A WBS review therefore checks the structure against the scope statement in both directions: everything in scope is present, and nothing excluded is.
• Project management work is project work. Planning, status reporting, stakeholder meetings and control take effort and cost, so they get their own branch, commonly called "project management". Leaving them out under-states the project and breaks the 100% rule.
• Reserves are not scope. Contingency reserve is budget within the cost baseline for responses to identified risks (known-unknowns). Management reserve is held outside the cost baseline, under management control, for unforeseen work within scope (unknown-unknowns). Neither one represents or replaces a part of the WBS.
• Go only as deep as needed. Once work packages can be estimated, assigned and monitored, further breakdown into hour-level tasks belongs in the schedule, not the WBS. The 8/80 rule of thumb (a work package of roughly 8 to 80 hours) is a heuristic, not a law.

Rolling wave planning and progressive elaboration

Progressive elaboration means adding detail as more becomes known. Rolling wave planning is the predictive form of it: near-term work is decomposed in detail, while distant or uncertain work is held at a higher level and refined later. Uncertain work is not left out of the WBS (that would break the 100% rule) and is not fully decomposed on guesses. When the budget for that later work is needed in the cost baseline now, it is represented as a planning package under a control account, which lets the cost baseline carry a budget for work that is known to exist but not yet detailed.

The WBS dictionary is the companion document that describes each WBS component in detail. The WBS shows that a work package exists; the dictionary says what exactly it is. A typical entry includes the code of account identifier, a description of the work, the responsible organization, assumptions and constraints, schedule milestones, associated schedule activities, resources and cost estimates, quality requirements, acceptance criteria, technical references and agreement information.

That makes it the place to settle boundary questions between work packages. When two contractors each assume the other is doing a piece of work that falls between their packages (for example, fixing cable trays at the point where the electrical and network installations meet), the agreed boundary is written into the dictionary entries of both packages. A responsibility assignment matrix complements the dictionary: it records who is accountable for each package, while the dictionary records what each package contains. It is also the document to hand a subcontractor who needs the full description, acceptance criteria and assumptions of the package they are delivering.

The scope baseline

The scope baseline is the approved version of three items: the project scope statement, the WBS and the WBS dictionary. It is the reference that delivered work and proposed changes are measured against. It is not the charter, the requirements list, or the schedule and cost baselines, although together with those it forms the performance measurement baseline.

Once approved, the baseline changes only through change control. A request is analysed for its impact and decided by the authorized body, whoever raises it. Change control applies equally to everyone: seniority does not bypass the analysis, and an approved baseline does not make change impossible, only controlled. When a change is approved, update the part of the baseline that changed. If the structure changes (a deliverable is added or removed), update the WBS and the dictionary. If only the description, quality requirements, acceptance criteria or other detail of an existing work package changes, the structure stays the same and the update goes in that package's WBS dictionary entry.

Agile projects break scope down into a product backlog: an ordered list of everything the product might need, owned by the product owner. Large items are progressively split into smaller ones as they approach delivery.

• Epic: a large body of work that will take several iterations and will be split into stories later (for example, "patients can book and manage clinic appointments online").
• Feature: a coherent piece of user-facing capability; many teams use it as the level between epic and story.
• User story: a small, valuable piece of user-visible behaviour, sized to finish within one iteration, with its own acceptance criteria.
• Task: the technical steps the developers break a story into during iteration planning.
• Spike: a time-boxed investigation to reduce uncertainty. It produces knowledge, not a usable product increment.

Good stories follow INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable. In practice that means each story can be completed within a single iteration and has testable acceptance criteria. Stories are not fully specified before refinement (they are negotiable), and they are estimated by the developers, not the product owner.

Splitting should produce vertical slices: each story delivers one user-visible behaviour end to end, through every layer it needs. "Patient books an available slot with one doctor" is a vertical slice. "Create the appointments table" is a horizontal, single-layer slice that nobody can use or accept on its own, and "book, reschedule, cancel and sync appointments to a calendar" bundles several behaviours that would not fit one iteration. Thin vertical slices are what make each story usable, demonstrable at the review and finishable in one iteration.

Just-in-time refinement

Backlog refinement is the agile equivalent of rolling wave planning. Items near the top of the backlog are detailed and ready; lower items stay as broad epics and are refined as they approach delivery. Detail is spent where it is about to be used, so effort is not wasted on work that may change or be dropped, while the broad epics further down keep the longer-term scope visible.

Formal acceptance is the point where the customer or sponsor confirms that a completed deliverable meets its agreed acceptance criteria. In predictive projects this is often called validating scope, and its order matters: the team first checks the deliverable internally for correctness against the quality requirements (control quality), producing a verified deliverable, and only then presents it to the customer for acceptance.

The order holds even under time pressure. Presenting unchecked work wastes the customer's time and risks accepting defects, and the customer's review does not replace the team's own quality check. Acceptance itself comes from the customer, or from whoever the agreement names as the customer's authorized representative; a sponsor from the performing side cannot accept on the customer's behalf.

In agile projects the product owner accepts or rejects completed stories, typically around the iteration review, against each story's acceptance criteria and the definition of done. A story that misses even one criterion is not done, however small the gap. Incomplete work returns to the product backlog, and its priority is then the product owner's decision, weighed against everything else in the backlog.

Managing scope means keeping delivered work equal to agreed scope: every change goes through the agreed route, and nothing is added informally, however small or well meant.

The right route depends on the approach:

• Predictive: assess the impact of the request on scope, schedule, cost, quality and risk, then submit it to change control. The size of a change does not exempt it from this route.
• Agile: a stakeholder who asks a developer directly for an addition mid-iteration is redirected, by the project manager as servant leader, to the product owner, who decides whether and where it goes in the backlog. The product owner, not the requester or an individual developer, decides what the team works on next.
• Hybrid: route the change by the component it touches. Work managed from a backlog goes to the product owner; work managed against a scope baseline goes through change control.

Tailoring scope definition for hybrid projects

Hybrid projects tailor scope by component. Parts whose requirements are fixed or mandated (a safety system that must meet a fixed industry standard, hardware with long lead times) are defined up front and baselined. Parts whose features are still being discovered with users are managed through a product backlog. Baselining an emerging component too early forces repeated change requests; managing a mandated component purely from a backlog loses the commitment the mandate requires.

The project still needs one integrated view of scope. A common pattern is to show the agile stream in the WBS at feature or release level, so both streams appear in one structure for reporting and budgeting, while the detailed stories live in the backlog. That keeps the predictive stream's detail and the agile stream's flexibility inside one structure.