What we put in a written scope

Discovery without a written scope turns into another workshop. The document is the product of discovery: what we will build, what we will not, and how we will know it worked.

Clients get the same sections every time. Familiar structure makes the hard decisions visible instead of buried in slide notes.

The sections that always appear

We keep the document short enough to read in one sitting and specific enough to estimate from.

1. 01
   Problem and success criteriaThe measurable change we are buying, not a feature list. Numbers beat adjectives.
2. 02
   In-scope workflowsNamed operators, systems, and the steps the first release will touch.
3. 03
   Out-of-scope listExplicit exclusions prevent polite scope creep from rewriting the engagement mid-build.
4. 04
   Sequence and checkpointsWhat ships first, what we learn, and when either side can stop without drama.

Out of scope is the useful half

The exact sections of the document a client gets after discovery, including the out-of-scope list.

If it is not written as out of scope, someone will assume it is free.

Why the document beats the meeting

Meetings evaporate. A scope with named exclusions becomes the reference when a new stakeholder joins in week three and asks for the dashboard that was never in the first slice.

A short test

Hand the draft to someone who missed discovery. If they cannot tell what is excluded, the document is not finished.