What Is Project Scope

A working definition

Project scope is the complete, agreed set of work required to deliver a project's outcome. By direct implication, it's also everything that falls outside that set. A scope statement that only lists what will be built is half a scope statement. The other half, the explicit list of what will not be built, is usually what prevents an argument three months later about whether something was "obviously" supposed to be included.

Scope is not a to-do list and not a schedule. It answers a narrower question than either: given this project, what counts as inside it? Everything else (who does the work, in what order, by when) is built on top of that answer, not part of it.

Scope statement vs. requirements document

These get used interchangeably and shouldn't be. A scope statement draws the boundary: what's in, what's out, at what level of detail. A requirements document lives inside that boundary and specifies, in much finer detail, exactly how each included piece should behave: field validation rules, performance thresholds, specific user flows.

The practical difference is who owns changes to each. Scope changes are business decisions; they usually cost money or time and need sign-off from whoever holds the budget. Requirements changes within an already-agreed scope are often just clarification, and a good team resolves dozens of them without escalating each one. Confusing the two categories is a common cause of both: requirements questions getting needlessly escalated as if they were scope changes, and genuine scope changes sliding through disguised as requirements detail.

Why written scope matters more than it seems to

An unwritten scope lives differently in every head that holds it. The client remembers the sales conversation where a feature was "definitely going to be included eventually." The developer remembers the ticket that specified something narrower. Neither is lying. They're both accurately reporting different conversations that were never reconciled into one document.

A written scope statement doesn't prevent disagreement. It moves the disagreement to a point where it's cheap to resolve, during scoping, before anyone has built anything, instead of a point where it's expensive, after work has been done on an assumption that turns out not to be shared. That timing shift is close to the entire value of writing scope down at all.

It also creates a reference point for every "can we also add" request that arrives later. Without a written baseline, there is nothing to compare a new request against, so every addition looks equally reasonable in isolation, which is precisely the condition that lets scope quietly grow unrecognised.

Self-check: is your scope actually written down?

• Could a new team member read the scope statement and know what's in and out, without asking anyone?
• Does it name things that are explicitly excluded, not just things that are included?
• Is there an agreed way to tell whether a deliverable is actually finished, beyond "it looks done"?
• If someone asked for something today, would you be able to point to whether it's already in scope or not?
• Has the written scope been updated the last time something was formally added, or is it now out of date?

Where ShipSprint fits in

Nothing here requires particular software. A scope statement is a document, and a plain page works fine. What actually helps is keeping that document somewhere it won't drift from the work it governs: ShipSprint's built-in wiki keeps a scope page next to the project's board instead of in a separate file people forget to check, with a history of edits so you can see exactly when and how the boundary changed. When a new request comes in, it lands in a triage inbox rather than someone's messages, which at least guarantees it gets weighed against the written scope instead of quietly agreed to in a hallway conversation.