Skip to content

Scope Statement

At a glance

  • Purpose: Define the boundary of the project — what will be delivered, what will not, and how completion will be recognised.
  • Use it when: After the charter, once requirements are understood enough to be bounded. It becomes the scope baseline, so changes to it go through change control.
  • Owner: The project manager, agreed with the sponsor and the business owner.
  • Related: Module 05 · Lab 06

How to use this template

  1. Write the exclusions first. It is far easier to see whether a project is finishable once you have said what it will not do.
  2. List in-scope items as deliverables, each with an acceptance criterion. "Reporting" is a theme; "a monthly summary export in CSV" is a deliverable.
  3. Make every acceptance criterion testable by a third party. If someone else cannot check it without asking you, rewrite it.
  4. Keep assumptions and constraints separate, and link to the Assumptions and Constraints Register rather than duplicating it.
  5. Mark each in-scope item required for launch or deferrable, so the first scope trade is a decision you have already prepared rather than an argument.

Field descriptions

Field What goes in it Watch out for
Business need Two or three sentences on the problem Restating the solution as the need
Product scope description What the product is, in bounded terms Defining the whole product instead of this release
In scope Numbered deliverables Themes and capabilities rather than deliverables
Out of scope Exclusions, each with a one-line reason Token exclusions nobody would have assumed
Acceptance criteria Testable conditions per deliverable "User-friendly", "robust", "modern"
Assumptions Beliefs the scope depends on Duplicating the constraints register
Constraints Limits you must work within Constraints invented in this document
Deferrable items What would be cut first, and why A deferrable list with no criteria

Blank template

# Scope Statement — [Project name]

| | |
| --- | --- |
| **Version** | [1.0 — this becomes the scope baseline on approval] |
| **Date** | [YYYY-MM-DD] |
| **Approved by** | [Sponsor / business owner] |
| **Related documents** | [Charter, requirements, WBS, risk register] |

## 1. Business need

[Why this project exists, in two or three sentences. No features.]

## 2. Product scope description

[What the system or deliverable is, at a level that bounds it. State the release, not the
product roadmap.]

## 3. In scope

| # | Deliverable | Acceptance criterion | Required for launch? |
| --- | --- | --- | --- |
| 1 | [Deliverable] | [Testable condition] | [Yes / Deferrable] |

## 4. Out of scope

| # | Excluded | Reason | Would return to scope if… |
| --- | --- | --- | --- |
| 1 | [Excluded item] | [Why] | [Condition] |

## 5. Acceptance criteria

[The conditions under which the sponsor will accept the deliverable as a whole. Reference the
per-deliverable criteria in section 3 rather than repeating them.]

## 6. Assumptions

[Link to the assumptions register; list only those the scope itself depends on.]

## 7. Constraints

[Link to the constraints register; list only those that bound the scope.]

## 8. Deferrable scope

| Item | Defer to | Reason it is deferrable |
| --- | --- | --- |
| [Item] | [Phase / release] | [Why the launch does not depend on it] |

## 9. Approval

| Role | Name | Date | Conditions |
| --- | --- | --- | --- |
| Sponsor | | | |
| Business owner | | | |

Worked example

From Lab 06, on the e-commerce platform. A request — "we need a proper online shop, customers should see what's in stock and track their delivery" — contains at least two ambiguities that belong in this document rather than in a designer's head:

As requested Ambiguity Assumption if forced Cost of being wrong
"see what's in stock" Live availability, or a nightly snapshot? Nightly snapshot Redesigning browse and checkout mid-build
"track their delivery" Courier tracking number, or live status? Tracking number as a link Integrating with two couriers who offer no interface
"run discounts" Percentage codes, or promotions with conditions? Whole-basket percentage codes Reworking pricing across the whole checkout
"look professional" Match competitors, or a defined brand direction? A short agreed visual direction Repeated redesign, and a subjective argument at the end

Note that the assumption column is a decision someone else owns, not a technical detail. Recording it here is what makes it possible to challenge.

Common mistakes

  • No exclusions, or trivial ones. An exclusion nobody would have assumed is not worth the line.
  • Themes instead of deliverables. "Reporting" cannot be accepted or rejected; "a monthly CSV summary" can.
  • Untestable acceptance criteria. Test each one: could a stranger verify it without you?
  • Slipping in scope at the end. Items discovered during writing belong in a change request, not quietly in the baseline.
  • Confusing scope with design. How something is built belongs in a design decision record; what is delivered belongs here.
  • Never revisiting it. When scope legally changes, update the baseline and record the change — an unmanaged drift leaves you with a document nobody trusts.