What is scope in and scope out?

'Scope in' is what the work explicitly includes; 'scope out' is what it explicitly excludes. Writing both — especially the out-of-scope list — sets a clear boundary so everyone agrees on what will and won't be delivered. The out-of-scope half is what prevents scope creep and the 'but I assumed that was included' conversation later.

Why is defining out-of-scope important?

Because scope creep and misaligned expectations usually come from things that were never explicitly excluded. If you only list what's in, people assume everything reasonable-sounding is also in. An explicit out-of-scope list makes the boundary visible, forces the hard conversations early, and gives you something concrete to point to when a new request arrives mid-delivery.

How do you define project scope?

Anchor it to the outcome. Everything genuinely needed to reach the agreed outcome is in scope; everything else — however reasonable it sounds — is out, at least for now. Write both lists explicitly, get them agreed by the requester and the team, and treat later additions as scope changes to be decided, not silently absorbed.

How to Write Scope In and Scope Out

Scope defines what the work includes and — just as importantly — what it excludes. The "in scope" list is the obvious half; the "out of scope" list is the one that actually protects you. Scope creep and the "but I assumed that was included" argument almost always come from things that were never explicitly excluded. Anchor scope to the outcome, write both halves, and you've turned a fuzzy expectation into an agreed boundary.

In scope and out of scope

In scope — what will be delivered. What the work includes.
Out of scope — what will not be delivered, stated explicitly. What the work excludes, even if it's reasonable, related, or someone assumed it.

Most scope documents write the first list and skip the second. That's exactly backwards: the second list is where the value is.

Why "out of scope" is the half that matters

If you only say what's in, everyone fills the silence with their own assumptions — and every stakeholder assumes their reasonable-sounding extra is included. Then, mid-delivery, the requests arrive: "and it'll handle the other entity too, right?" You have nothing to point to, so you either absorb the creep or have an awkward fight.

An explicit out-of-scope list does three things: it makes the boundary visible, it forces the hard conversations early (when "no, that's out" is cheap), and it gives you a concrete reference when a new ask appears later.

Scope creep isn't caused by new requests. It's caused by boundaries that were never drawn — so every request looks like it was always included.

How to define scope from the outcome

Scope falls out of the outcome. The test for every candidate item is simple:

Is this genuinely needed to reach the agreed outcome?

Yes → in scope.
No → out of scope, at least for now — however reasonable it sounds.

This keeps scope tied to what actually matters and stops the drift toward "while we're in there, let's also…" that quietly doubles the work.

An example

Outcome: "Month-end exposure by entity is produced automatically and reconciles first time."

In scope: exposure by entity; the automated month-end feed; reconciliation to the source.
Out of scope: exposure by counterparty (next phase); intraday/real-time exposure; currencies beyond the group's top five; a redesign of the underlying data model.

Now, when someone asks for counterparty exposure mid-build, it's not a fight — it's a scope change to be decided, because you already said it was out.

Handling scope changes

Out-of-scope isn't "never" — it's "not in this piece of work." When a genuine new need appears, treat it as a scope change: name it, decide it explicitly (does it change the outcome, the date, the effort?), and either bring it in with eyes open or park it. What you're avoiding is scope changing by silent absorption, where the boundary erodes one reasonable request at a time until the work is unrecognizable and late.

What usually goes wrong

No out-of-scope list. Only "in scope" is written, so every assumption is "in" until proven otherwise.
Gold-plating. "While we're here, let's also…" — scope grows toward what's interesting, not what's needed.
Scope by omission. Boundaries that exist only in one person's head, so different people hold different scopes.
Silent absorption. New requests folded in without a decision, so the date slips and no one can say when it happened.

Write both halves, anchor them to the outcome, agree them with the requester and the team, and treat additions as decisions — and scope stops being the thing that quietly sinks the delivery. This is why Delivery Sheet makes scope-in and scope-out explicit fields: the boundary is drawn before the work starts, not argued about after.

Part of the Finance Systems Delivery guide. See also defining a measurable outcome and the project intake process. The newsletter sends one finance-systems pattern every two weeks.