Develop and Manage Project Scope

Introduction

This lesson covers Task 2.2 of the Process domain of the July 2026 PMP Examination Content Outline (ECO), a domain worth 41% of the scored questions. The task has four enablers: define scope (requirements, scope statement, product backlog); obtain stakeholder agreement on the scope; break down scope (work breakdown structure, epics and user stories); and establish the definition of done and acceptance criteria for deliverables.

Scope is the main source of project disputes. The exam describes requirements that are vague, stakeholders who disagree about what is included, a team that adds features nobody asked for, a backlog without priorities, a WBS that lists activities instead of deliverables, or a deliverable rejected because nobody defined "done". You are expected to choose the action that clarifies, agrees and controls scope using the approach that fits the project.

After this lesson you will be able to collect and document requirements, write a scope statement or manage a product backlog, secure agreement, decompose scope with a WBS or into epics and stories, and write acceptance criteria and a definition of done.

Learning objectives

• Distinguish product scope from project scope, and requirements from solutions.
• Collect requirements with appropriate techniques and document them.
• Write a scope statement and manage a product backlog.
• Obtain and record stakeholder agreement on scope, and control changes.
• Build a WBS with a WBS dictionary, and break epics into user stories.
• Write acceptance criteria and a definition of done, and validate and verify deliverables.

1. Product scope, project scope and requirements

Product scope is the features and functions of the product, service or result. Project scope is the work needed to deliver it. The project is complete when both are delivered as agreed.

A requirement is a condition or capability that must be met. Types:

State requirements as needs and outcomes, not as solutions, until the solution is chosen: "customers can pay by their usual method" is better than "add a PayPal button". Each requirement should be clear, testable, traceable to a business need, and prioritised.

Collecting requirements

The requirements traceability matrix links each requirement to its source, objective, deliverable, and test, so that nothing is built without a reason and nothing required is forgotten.

Example: finding the real requirement

A regional bank's manager asks for "a faster report". Observation shows that branch staff export data to a spreadsheet, correct 12 fields manually, then send the file by e-mail every Monday; the delay comes from the corrections. The real need is "branch staff receive correct weekly figures without manual work". A faster report would not have solved it. Interviews and observation revealed the requirement behind the request.

2. Defining scope: the scope statement and the backlog

In a predictive project, the project scope statement describes:

• Product scope description, with the deliverables and the acceptance criteria.
• Exclusions: what is explicitly out of scope (very useful to prevent assumptions).
• Constraints and assumptions.

The scope statement, WBS and WBS dictionary together form the scope baseline. Any change to it goes through change control.

In an adaptive project, the scope is held in a product backlog, an ordered list of everything the product might need, owned by the product owner. It is dynamic: new items appear, items are refined, reprioritised or removed. The vision and the roadmap give the frame; the product owner orders the backlog by value, risk, dependencies and cost. Only the items near the top are detailed ("just-in-time" refinement).

Example: the scope statement that prevents an argument

For a conference app, the scope statement includes the exclusion "web version and native tablet layouts are out of scope for release 1". Three months later, the marketing director asks for a tablet version. Because the exclusion was agreed and signed, the discussion becomes a change request with an impact analysis (6 weeks, EUR 48,000) instead of an argument over what was promised.

3. Stakeholder agreement on scope

Agreement is not a formality; it is how scope disputes are avoided.

• Involve the right people: sponsor, customers, users, operations, regulators, suppliers and the team. Missing groups produce late requirements.
• Resolve conflicts between requirements with facilitated workshops, prioritisation and decision rules, and escalate to the sponsor when stakeholders cannot agree.
• Document and sign off the requirements and the scope statement (predictive), or agree the vision, the roadmap and the release goals and the product owner's authority (adaptive).
• Confirm shared understanding: show prototypes, walk through examples, ask people to restate requirements.
• Link scope to the business case: every requirement should support a benefit; items without one are candidates for removal.
• Control scope creep and gold plating. Scope creep is uncontrolled growth without adjusting time, cost and resources. Gold plating is the team adding unrequested extras. Both are managed by sticking to the agreed scope and using change control or backlog prioritisation.

Verify scope vs validate scope vs control quality

The usual order: verified deliverables first, then validation by the customer. In agile, validation happens at every iteration review, where the product owner accepts or rejects items against acceptance criteria.

Worked example: handling a conflict between stakeholders

Statement. In a hospital patient-portal project, the clinical director wants appointment booking in release 1; the finance director wants online payment first, because it brings revenue; the IT security manager says neither can go live without multi-factor authentication. The sponsor gave a budget for roughly two of the three features. Workshop discussions stall.

Reasoning, step by step.

1. Clarify the underlying objectives: patient access (clinical), cash flow (finance), compliance (security).
2. Security is a regulatory constraint, so authentication is mandatory for any release (a constraint, not a competing feature).
3. Estimate cost and value of booking and payment with the team. Booking: 160 points, reduces phone calls by an estimated 30%. Payment: 200 points, new revenue of EUR 400,000 per year but needs a payment provider contract (4 weeks).
4. Use a prioritisation technique (weighted value-versus-cost scoring or MoSCoW) in a workshop, with the sponsor's decision rule if no consensus.
5. Result: release 1 has authentication and booking; release 2 adds payment; the decision is recorded in the product backlog and communicated.

Why not the alternatives? Satisfying the loudest voice would ignore the constraint; trying to build all three exceeds the budget; asking the team to choose pushes a business decision onto the wrong people.

4. Breaking down scope

Work breakdown structure (WBS)

The WBS is a hierarchical decomposition of the total scope into deliverables. The lowest level is the work package, which can be estimated, scheduled and assigned. Key rules:

• 100% rule: the WBS includes all the work and only the work in scope, and children add up to the parent.
• It is organised by deliverables or phases, not by activities or departments.
• Level of detail: enough to estimate and manage (often cited as 8 to 80 hours, or 1 to 2 reporting periods, but these are rules of thumb).
• Rolling wave planning: near-term work is decomposed in detail; later work stays at a higher level until more is known.
• The WBS dictionary describes each element: description, acceptance criteria, responsible, schedule milestones, cost, quality requirements, assumptions.
• A control account links WBS and cost accounts.

Example of a WBS (extract) for a retail website

• 1 Retail website
  • 1.1 Design: 1.1.1 User research report, 1.1.2 Wireframes, 1.1.3 Visual identity
  • 1.2 Catalogue: 1.2.1 Product database, 1.2.2 Search function
  • 1.3 Checkout: 1.3.1 Basket, 1.3.2 Payment integration, 1.3.3 Order confirmation
  • 1.4 Testing and launch: 1.4.1 Test report, 1.4.2 Trained support team, 1.4.3 Live site
  • 1.5 Project management: 1.5.1 Plans and reports

Notice that every element is a noun (a deliverable). "Write code" or "Hold meetings" would be activities and belong in the schedule.

Decomposition techniques use the same logic as the 100% rule: top-down by phases or deliverables, bottom-up from lists of tasks, or templates from previous projects.

Epics, features and user stories

In agile projects, scope is broken down differently:

A user story is usually written: "As a role, I want capability so that benefit." Good stories follow INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Story mapping arranges stories along the user's journey to see a minimum viable release. Spikes are time-boxed investigations to reduce uncertainty. Splitting techniques: by workflow step, by business rule, by data variation, by user role, by happy path versus exceptions.

Example. The epic "Customers manage their delivery" is split into stories: "As a customer, I want to see my delivery status so that I know when to be home"; "As a customer, I want to change the delivery date so that I can avoid missing it"; "As a customer, I want an SMS when the driver is 15 minutes away so that I can prepare". Each can be built, tested and accepted separately.

5. Acceptance criteria and the definition of done

Acceptance criteria are the conditions that a deliverable (or a story) must meet to be accepted. They are specific, measurable and agreed before work starts.

Common formats:

• A list of rules: "Password must have at least 12 characters; the user sees an error message if it does not."
• Given / When / Then scenarios: Given a customer with an unpaid invoice, When they open the account page, Then the page shows the balance and a "Pay now" button.

The definition of done (DoD) is a shared checklist that applies to every item of the product: for example, code reviewed, unit and integration tests passed, documentation updated, security scan with no critical findings, accepted by the product owner. Acceptance criteria are specific to an item; the DoD is common. A definition of ready may state when a story is clear enough to enter an iteration.

In predictive projects, acceptance criteria appear in the scope statement and the WBS dictionary, and acceptance is formal (signature on a deliverable acceptance form).

Worked example: writing acceptance criteria

Statement. The story: "As a returning customer, I want to log in with a one-time code sent to my phone so that I do not have to remember a password." Write acceptance criteria and identify what belongs in the definition of done.

Reasoning.

1. Identify the behaviours: sending the code, entering it, expiry, errors, limits.
2. Write criteria that can be tested:
   • Given a registered phone number, when the customer requests a code, then an SMS with a 6-digit code arrives within 30 seconds.
   • Given a valid code, when it is entered within 5 minutes, then the customer is logged in.
   • Given an expired or wrong code, when it is entered, then access is refused and an error message is displayed.
   • Given 5 failed attempts, then the account is locked for 15 minutes.
3. Put in the DoD (common to all stories): code reviewed, automated tests pass, security scan done, accessibility checked, release notes updated.
4. Check testability: each criterion has a clear pass or fail.

Why not "The login must be easy and secure"? It cannot be tested, so different people would accept or reject it differently.

6. Controlling scope

Scope control monitors status and manages changes to the baseline.

• Predictive: compare delivered work with the baseline; analyse variance; every change is a change request with impact on schedule, cost, risk, quality and resources, approved by the change control board (see Task 3.3).
• Adaptive: new requests become backlog items; the product owner decides priority; if adding work would breach the date or budget, something of lower value is removed or the sponsor decides on more funding.
• Both: keep the traceability matrix current, review scope at milestones or iteration reviews, record decisions, and communicate changes.

Handle a verbal request from a senior stakeholder ("just add this, it's small") by assessing and recording it as a change, not by quietly absorbing it.

7. Common pitfalls and exam tips

Pitfalls

• Documenting solutions instead of needs.
• Skipping exclusions in the scope statement.
• Building a WBS from activities or by department.
• Treating the backlog as a fixed list or leaving it unprioritised.
• Accepting verbal changes from powerful stakeholders.
• Gold plating, or adding features that were not requested.
• Writing acceptance criteria that cannot be tested, or writing them after the work.
• Confusing verification (meets specification) with validation (customer accepts).

Exam tips

• When requirements are vague, the best action is to elicit and clarify with stakeholders (interviews, workshops, prototypes), not to guess or start building.
• When stakeholders conflict, facilitate and use prioritisation; escalate to the sponsor if needed.
• WBS elements are deliverables; the lowest level is a work package; the 100% rule applies.
• In agile, the product owner owns and orders the backlog; the team does not add items on its own; changes are managed by reprioritisation.
• Acceptance criteria are specific to an item; the definition of done applies to all items.
• A request for a change after baseline means a change request in predictive work, and a backlog change in adaptive work.
• Validation is done by the customer or sponsor; control quality precedes it.

8. Mini case study

Situation. You manage a project for a municipality to launch a residents' portal for permit applications within nine months. Different departments gave long, partly contradictory wish lists: planning wants 14 form types, the mayor's office wants a "modern look" and a mobile app, IT wants integration with the legacy records system, and the legal department insists on accessibility and data-protection compliance. The sponsor has a fixed budget. The team is cross-functional and has used Scrum before. Three weeks in, the mayor's office asks you in a corridor to add a chatbot, "it should be quick".

Question. How do you define and manage the scope?

Model solution.

1. Choose the form. The date and budget are fixed and the requirements are uncertain, with legal constraints: a hybrid frame with a product backlog, release milestones and compliance criteria.
2. Elicit requirements through workshops with each department and observation of counter staff handling permits; separate needs (applications are completed and tracked online) from solutions (mobile app, chatbot); document non-functional and legal requirements as constraints.
3. Write the vision and scope boundaries, including exclusions for release 1 (native mobile app, chatbot).
4. Prioritise with a workshop and a weighted scoring on value, cost and risk; the most frequent 4 form types first (they represent 70% of applications); the sponsor decides tie-breaks.
5. Break down: epics (apply, pay, track, notify), stories with INVEST criteria, a story map for release 1; a WBS-style outline for the non-backlog work (legal review, data migration, training).
6. Acceptance criteria in Given/When/Then for each story; a definition of done including accessibility check, security scan, data-protection review.
7. Agree: obtain written agreement from the sponsor and department heads on the vision, release 1 scope, exclusions and the product owner's authority.
8. Handle the chatbot: do not accept it informally. Record it as a backlog item, estimate it, and take the value and cost to the product owner and sponsor; if it is added, something else moves out or additional funding is approved.
9. Control and validate: refine the backlog each sprint; sprint reviews with the product owner and users for acceptance; report scope progress by release burn-up.

Key terms

• Requirement: a condition or capability that must be met.
• Scope statement: description of deliverables, acceptance criteria and exclusions.
• Scope baseline: approved scope statement, WBS and WBS dictionary.
• Product backlog: the ordered list of work for a product, owned by the product owner.
• WBS / work package: hierarchical decomposition of deliverables / its lowest level.
• 100% rule: the WBS contains all the work, and only that work.
• Epic / user story: a large body of work / a small statement of user value.
• Acceptance criteria: conditions for accepting an item.
• Definition of done: shared checklist applied to all items.
• Scope creep / gold plating: uncontrolled growth / unrequested extras.
• Requirements traceability matrix: links requirements to sources, deliverables and tests.

Summary checklist

• I collect requirements as needs with suitable techniques, and I trace them.
• I document scope with a scope statement and exclusions, or a prioritised product backlog.
• I obtain and record stakeholder agreement and resolve conflicts through facilitation and prioritisation.
• I build a WBS of deliverables with a dictionary, or break epics into INVEST stories.
• I write testable acceptance criteria and a shared definition of done.
• I control changes through change requests or backlog prioritisation, and I validate deliverables with the customer.

Official sources

• PMI, PMP Examination Content Outline (July 2026), Process domain, Task 2.2: https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf (opens in a new tab)
• PMI, New PMP exam: https://www.pmi.org/certifications/project-management-pmp/new-exam (opens in a new tab)