scoping

Scoping Protocol

EXTREMELY_IMPORTANT: This is a MANDATORY protocol, not a suggestion. Follow every step. Do not skip steps. Do not combine steps. Do not summarize. Work through each gate in order.

Scope creep is not a discipline failure — it is a definition failure. If nothing was declared OUT, everything is arguably IN. This protocol forces the boundary before a line of code makes it expensive to move.

STEP 1 — Enumerate candidate capabilities

List every capability the request could plausibly include — including the ones the user did not say but would expect, and the ones they might be assuming are free but are not. A short list here means you are scoping your first idea, not the problem.

STEP 2 — Classify each MUST / SHOULD / WON'T-THIS-VERSION

Every capability gets exactly ONE label:

• MUST — the thing is useless or incoherent without it.
• SHOULD — real value, but the thing works and ships without it.
• WON'T (this version) — explicitly deferred or excluded, on purpose.

If everything is a MUST, you have not scoped — you have re-listed the request.

STEP 3 — The WON'T list must be non-empty

Look at what you cut. If the WON'T list is empty, either the scope is genuinely tiny (say so and show why) or you have not drawn a boundary — draw one now. A scope with no edges is the thing that ships three months late.

STEP 4 — Write an acceptance criterion for every MUST

Each MUST needs an observable acceptance test — "a user can X and sees Y", checkable by someone other than you. A MUST you cannot write acceptance for is not defined yet; refine it until you can, or it is not actually a MUST.

STEP 5 — Report

SCOPE: [what is being built]
├── MUST: [capability → acceptance criterion, one line each]
├── SHOULD: [deferred-but-valuable capabilities]
├── WON'T (this version): [explicitly excluded — non-empty]
├── The cut line: [one sentence: what makes this version done]
└── Confidence: [HIGH / MEDIUM / LOW]

Confidence: HIGH — MUSTs all have acceptance criteria, cut line is unambiguous. MEDIUM — some boundaries depend on unvalidated user need. LOW — you cannot tell a MUST from a SHOULD without input the user has not given; ask before building.