5.3 Define Scope
Turn the gathered requirements into a clear statement of what is in and out.
Planning / Scope · ← PMBOK reference · See it on the map
Why it matters
A vague scope statement leaves room for everyone to read it their own way, and that gap is exactly where scope creep gets in.
What done looks like
A scope statement exists naming what is included and, just as clearly, what is not.
First time tip
Write the exclusions as plainly as the inclusions. What you are not doing prevents more arguments later than what you are doing.
What you need (Inputs)
- Project Charter
- Scope Management Plan
- Requirements Documentation
How Scrum/Kanban projects satisfy this — counted from: backlog items (driftless/models/agile.py:BacklogItem) — a backlog item's description IS its requirement statement; present once any item has one, healthy once every item does - Assumption Log
- Risk Register
- Organizational Process Assets
How you do it (Tools & Techniques)
What you get (Outputs)
Worked example
The scope statement says the project repaints the reading room, replaces the shelving and adds teen-room outlets, and explicitly excludes the roof, which the board keeps raising but has never funded.
Common pitfalls
- Listing only inclusions and letting exclusions stay implied.
- Writing the statement so vaguely two readers could disagree on what it covers.
- Leaving out a boundary a stakeholder has already raised more than once.
How driftless helps
- Product Analysis can be run here.
- Project Scope Statement can be created in the wizard.
- Assumption Log can be created in the wizard.