4.2. Develop and Manage Project Scope

💡 First Principle: Scope isn't "whatever's in the charter" — it's actively defined, agreed to, and broken down into a shared, unambiguous understanding, because vague scope is where schedule and cost overruns actually originate.

Enablers: define scope, obtain stakeholder agreement on scope, and break down scope (into a WBS, backlog, or equivalent decomposition depending on approach).

Obtaining explicit stakeholder agreement — not just documenting scope and assuming buy-in — is the enabler most commonly missed in practice and most commonly tested: a scope statement that was written and circulated but never explicitly confirmed with the key stakeholder is a documented scope in name only.

Defining scope starts with requirements

Before scope can be defined, requirements must be elicited, and a new or unsure team needs a method first: a requirements management plan sets out how requirements will be gathered, documented, traced, and changed. The vision and charter are then progressively elaborated into a coordinated approach as more becomes known.

When stakeholders cannot articulate what they want, or hold different pictures of the same feature, stop asking them to describe it and show them something. Prototypes, mockups, wireframes, storyboards, and demos of partial work let the product owner, stakeholders, and team see, adjust, and agree. Under high ambiguity with many possible options, combine experiments and prototypes with progressive elaboration rather than forcing early commitment.

Breaking scope down: predictive and agile

The WBS is a hierarchical decomposition of the total scope into deliverables, showing what will be delivered; the schedule sequences that work over time, showing when. The WBS comes first. Cost and duration estimates are most reliable at the work package level, so a module whose estimates keep missing was probably never decomposed far enough — decompose it further. A product breakdown structure shows the deliverables themselves and how each part relates to the others.

Once decomposition is agreed, baseline the scope and record it under configuration management so later changes go through the proper process.

In agile, a team holding a WBS and a scope statement bridges into sprints by grouping work into epics of customer value and splitting them into stories small enough for a sprint. Story mapping arranges stories along the user's journey so the team understands what a feature does and which slice to build first. Rather than a months-long upfront breakdown of the whole deliverable, timebox work on the highest-priority backlog items, update estimates, and reprioritize.

⚠️ Exam Trap: Answering an agile scenario with "complete the full WBS and requirements set before starting." Adaptive scope is elaborated just in time; the backlog is a living list that evolves with feedback, while a scope statement fixes boundaries at a point in time.

User stories, acceptance criteria, and done

A user story describes a capability from the perspective of the person who wants it. The Three Cs are Card, Conversation, Confirmation — after the card is written, the crucial step is the conversation among developers, testers, and the product owner about how the feature will be used. Acceptance criteria are the conditions a story must meet to be accepted; they should be clear, verifiable, and traceable, and are set during estimation and elaboration with the product owner, business analyst, and team. Behavior-driven development writes them as Given, When, Then.

When a team is unsure how much work a story needs before the sprint review, the answer is its acceptance criteria plus the team's definition of done — not the product owner's opinion on the day.

Backlog refinement is the ongoing activity where the product owner and team clarify, split, estimate, and reorder upcoming items. Hold it mid-sprint when too little work is ready for the next sprint, and use it when delivered features drift from current market value. A sprint burndown that rises mid-sprint, with nobody adding stories, usually means stories entered the sprint under-refined and ambiguity surfaced during build.

Managing scope once work begins

With requirements and scope signed off and execution under way, the work is monitored and controlled against the baseline. A mid-project request for new scope follows a fixed order: clarify what is being asked and why, assess its impact on schedule, cost, and quality, route it through change control for a decision, and only then update the baseline and plans. Items outside the approved baseline are out of scope until a change adds them.

Once a scope change is approved with its funding, the money for work nobody planned for comes from the management reserve, released through the PMO or sponsor — not by quietly absorbing it into the existing budget.

⚠️ Exam Trap: Assuming persistent scope creep means the change process is missing. More often the process exists on paper but stakeholders go straight to team members with informal requests, and the team implements them without approval. Fix the behavior, not the form.

In agile, a new high-benefit, low-complexity idea goes into the backlog and is reprioritized — possibly to be next. When customers add features but the deadline is fixed, make sure they understand that lower-priority features may drop off: time is fixed, scope flexes. The same flexibility belongs in agile vendor contracts — the contract must accommodate changes to product scope, which is why cost-reimbursable forms such as cost plus incentive fee suit uncertain scope while firm fixed price suits well-defined work with an experienced vendor. For simple, well-understood purchases, a request for quotation is the usual bid document; a request for information comes first when you still need to learn what the market offers.

Scope estimates mature too: an early range of 53 to 75 days is neither accurate nor precise, and the right move is to note that and refine it as the project progresses. Scope completion is never the finish line on its own — a project that delivers every planned item but none of the intended benefit has succeeded in execution and failed in purpose.

⚠️ Exam Trap: Treating scope as fully "managed" once it's written down. If a scenario shows disagreement or confusion surfacing later about what's included, the root cause PMI is testing for is usually "agreement was never actually obtained," not "the document was unclear."