Defining scope and acceptance

Requirements describe what stakeholders need. Scope describes what the project will actually deliver to meet those needs, and just as importantly what it will not deliver. This lesson covers the project scope statement and its parts, product analysis and alternatives, acceptance criteria and the definition of done, the difference between validating and controlling scope, and the twin problems of scope creep and gold plating. It also shows how scope is handled in adaptive work, where the backlog is the scope and the question is how to keep it under control without freezing it.

Product scope and project scope

Product scope is the set of features and functions that characterize the product, service or result. Project scope is the work performed to deliver it, including management, training and transition work. Completion of product scope is measured against requirements; completion of project scope is measured against the project management plan. For Project Compass, product scope includes the fitted-out branch, the working kiosks and gates, and the app's features. Project scope also includes the project management, the tendering of the construction contract, staff training and the collection move.

The project scope statement

In a predictive project, the scope statement is the detailed description of the project's deliverables and the work needed to create them. It builds on the high-level description in the charter and on the requirements documentation. A good scope statement gives everyone a common understanding and becomes the basis for the WBS, estimates and later decisions about whether a request is in or out of scope.

Exclusions deserve special attention. Stakeholders tend to assume that anything related to the project is included. Writing down what is not included, and getting the sponsor to agree, prevents later disputes. Assumptions also matter because each is a potential risk: if the ceiling does contain hazardous materials, the project faces cost and delay. Assumptions and constraints are recorded in an assumption log and reviewed as the project progresses.

In Canada, the building assumptions would be checked against the provincial building code and the municipality's permit process, and the accessibility requirements against provincial accessibility standards and the library's own design standards.

Product analysis and alternatives

Product analysis translates high-level product descriptions into tangible deliverables. Techniques include product breakdown, systems analysis, value engineering and value analysis. Alternatives analysis looks at different ways to deliver the scope. For Project Compass, the team compared tagging the collection with RFID versus keeping barcodes with self-checkout scanners. RFID costs more but allows faster checkout, security gates and quicker inventory; barcodes are cheaper but slower. The board chose RFID because staff time saved on inventory and holds supported the branch's staffing model. Recording the alternatives considered and why one was chosen helps later when someone asks why the project is not doing the cheaper option.

Value engineering looks for ways to deliver the required function at lower life-cycle cost. For example, the design team proposed polished concrete floors in the main collection area instead of carpet tiles. Initial cost was similar, but maintenance and replacement costs over 20 years were much lower. Value engineering is not simply cutting scope; it keeps the function while changing the means.

Acceptance criteria and the definition of done

Acceptance criteria state the conditions a deliverable must satisfy for the customer or sponsor to accept it. They should be agreed before the work is done, not argued about afterwards. In predictive projects, they appear in the scope statement and are detailed in the WBS dictionary and test plans. In adaptive projects, each backlog item has acceptance criteria, and the team also works to a definition of done that applies to every item, such as code reviewed, automated tests passing, accessibility checked and documentation updated.

Acceptance criteria connect directly to quality. A deliverable can be built exactly as designed and still fail acceptance if the criteria were never agreed. Conversely, criteria that are too vague invite disputes. PMP-131 covers quality planning and control in detail; for scope, the key point is that each deliverable should have criteria that are objective and agreed in advance.

Validating scope versus controlling scope

These two are often confused. Validating scope is the formal acceptance of completed deliverables by the customer or sponsor. It is mainly about acceptance. Controlling quality, which usually comes first, is about correctness: checking that the deliverable meets the quality requirements. A typical sequence is that the team builds a deliverable, quality control verifies it against specifications, and then the customer reviews it and formally accepts it in validate scope. In adaptive projects, the sprint review plays a similar role, with the product owner accepting or rejecting completed items.

Controlling scope is monitoring the status of scope and managing changes to the scope baseline. It involves comparing work performed with the baseline, identifying variances, and making sure that requested changes go through integrated change control. The aim is not to prevent all change, but to make sure that changes are deliberate, assessed and approved.

Scope creep and gold plating

Scope creep is uncontrolled expansion of scope without adjustments to time, cost and resources. It usually arrives in small increments: an extra report here, a slightly larger room there, each too small to seem worth a change request. Gold plating is the team adding features or quality the customer did not request, often with good intentions. Both consume resources and introduce risk. The cure is the same: clear scope documents, a known path for changes, and a team culture that delivers what was agreed and raises new ideas as proposals rather than quietly building them.

Scope in adaptive work

In adaptive projects, the product backlog is the scope. It is expected to change as the team and stakeholders learn. Control comes from ordering the backlog by value, keeping a clear product goal, protecting each iteration from mid-iteration changes and measuring both delivery and scope change. A burn-up chart shows completed work and total scope on the same chart, so stakeholders can see whether scope growth is pushing the finish further away.

# Mobile app backlog for Project Compass: is scope growing faster than delivery?
# (invented sprint data, story points)
sprints = [  # (sprint, points completed, total backlog size at end of sprint)
    (1, 18, 220), (2, 21, 226), (3, 20, 238), (4, 23, 241), (5, 22, 255), (6, 24, 262)]

done = 0
prev_total = 220
print("Sprint  Done  Cum done  Backlog  Added  Remaining")
for s, pts, total in sprints:
    done += pts
    added = total - prev_total
    prev_total = total
    print(f"{s:6d} {pts:5d} {done:9d} {total:8d} {added:6d} {total - done:10d}")

velocity = done / len(sprints)
growth = (sprints[-1][2] - 220) / len(sprints)
remaining = sprints[-1][2] - done
print(f"\nAverage velocity: {velocity:.1f} points per sprint")
print(f"Average scope growth: {growth:.1f} points per sprint")
print(f"Net burn: {velocity - growth:.1f} points per sprint")
print(f"Sprints to finish at current rates: {remaining / (velocity - growth):.1f}")
print(f"Sprints to finish if scope froze now: {remaining / velocity:.1f}")

Sprint  Done  Cum done  Backlog  Added  Remaining
     1    18        18      220      0        202
     2    21        39      226      6        187
     3    20        59      238     12        179
     4    23        82      241      3        159
     5    22       104      255     14        151
     6    24       128      262      7        134

Average velocity: 21.3 points per sprint
Average scope growth: 7.0 points per sprint
Net burn: 14.3 points per sprint
Sprints to finish at current rates: 9.3
Sprints to finish if scope froze now: 6.3

After six sprints, the team has completed 128 points at an average of 21.3 points per sprint, but the backlog has grown by an average of 7 points per sprint. The net burn is only 14.3 points per sprint, so finishing the current backlog would take about 9.3 more sprints, against 6.3 if scope stopped growing. This is not automatically bad: some additions may be high-value features discovered through user testing. But the product owner needs to make a deliberate choice: accept a later release, drop lower-value items, or fix the release 1 scope and move new ideas to release 2. Making this visible is the point.

Minimum viable product (MVP) thinking helps keep adaptive scope in check. Release 1 of the app might include only availability search, holds and account management; room booking and event registration follow in release 2. Each release should be valuable on its own, and the team learns from real use before building more.

Who decides scope

In a predictive project, the sponsor and key stakeholders approve the scope baseline, and a change control board or delegated authority approves changes. In an adaptive project, the product owner decides the order of the backlog within the product goal and budget agreed with the sponsor. The project manager or team facilitates, assesses impact and keeps records, but does not unilaterally add or remove scope. An exam answer in which the project manager simply agrees to a stakeholder's request, or refuses it outright, is usually wrong; the right answer routes it to the appropriate decision-maker with impact information.