Scope is mostly what you're not doing

Every scoping document has two lists. The in-scope list gets written carefully, reviewed, and agreed. The out-of-scope list gets three bullets added at the end by whoever is closing the doc.

Then week six arrives, somebody asks for one more thing, and it is the second list that would have held the line — if it had said anything.

In-scope describes an intention you already share

By the time a demand is being scoped, everyone in the room broadly agrees what the work is. Writing that down is useful as a record, but it is not doing much work: nobody is confused about the main thing.

The disagreements live at the edges — the adjacent thing that would be "easy while you're in there", the second use case, the migration of the old data. Those are precisely what an in-scope list does not mention, because they were never discussed as inclusions. They arrive later as small favours.

An exclusion is a decision, so record it like one

"Out of scope: reporting" is nearly useless. It does not say whether reporting was considered and rejected, forgotten, or deferred — and those have completely different consequences when someone asks for it.

What makes an exclusion hold is the same shape as any other decision record : what is excluded, why, and what would change it.

"Not the historical data migration — the new schema lands in Q4 and doing it twice costs more than waiting" is a sentence somebody can argue with, check, or act on. It also survives its author leaving, which the three-bullet version does not.

The week-six conversation

This is the whole return on the effort, so it is worth being concrete.

Without a real exclusion list, the request is "can we also do X?" — an open question with no reference point, answered by whoever has the most authority in the room. The cost is invisible and the answer is usually yes.

With one, the request becomes "we decided in week one not to do X, because Y. Has Y changed?" That is a different conversation: it has a fact in it, it is answerable by the people present, and if Y genuinely has changed then including X is a considered re-decision rather than a favour.

Notice the exclusion list does not say no. It makes the cost of yes visible before it is paid, which is all any governance artifact should try to do.

Scope creep is usually a scoping failure

The phrase implies the scope grew on its own. Mostly it did not — the scope was always this size, and the initial description just did not cover the parts nobody thought to mention.

That reframing matters, because the two have different fixes. If work genuinely grows, you need change control. If the scope was underdescribed, you need the exclusion list — and no amount of change control substitutes for it, since a change process cannot detect a change from an unstated baseline.

Keep it short

An exclusion list that tries to be exhaustive is a list nobody reads, and a long one is a tell: if you need thirty exclusions, the demand is too big and the real answer is to split it.

Three to five, chosen for the ones somebody will plausibly ask for. You are not enumerating the universe, you are pre-answering the specific questions you can already predict — which after a few quarters in one organisation is most of them.

How DeliverySheet handles it

Scope is captured as two explicit lists on the demand, in and out, and both are part of the commitment baseline rather than free-text notes attached to it. The summary shows the counts — "4 in / 3 out" — which is a small thing that does real work: a demand with a full in-scope list and an empty out-of-scope list is visibly half-scoped at a glance.

Because scope is part of the baseline, changing it after commitment is a re-baseline with a recorded reason rather than an edit, and the commitment ledger keeps the original alongside what it became. That is the mechanism that turns "the scope grew" from a feeling into something you can point at — the same machinery behind recording what actually shipped against what was promised .