The scope that never got said out loud

Most scope problems aren't discovered in the work.

They're discovered in the review.

Three weeks in. First demo. And everyone in the room realises they were building slightly different things.

Not because anyone was careless. Because nobody said the scope out loud. They assumed it was obvious.

It wasn't.

Scope problems show up in the work. They started in the kick-off.

The tell

Ask the three people closest to the work to each write down — independently — what the team is building and what it isn't building.

If you get three different versions, you don't have a scope problem.

You have a communication problem that's about to become a delivery problem.

The fix (it takes one paragraph)

Before the work starts, one person writes this down:

"We are building [X] for [who]. We will know it's done when [outcome]. We are not building [Y]."

Read it to the room. Every "but what about…" is scope you haven't decided yet.

Not a brief. Not a requirements doc. One paragraph that forces the room to agree on what done actually looks like.

If the room can't agree on the paragraph, you're not ready to start. You've just decided to find out the hard way.

The VOLTS move

The output here is a Clarity Statement. No Clarity Statement means everyone ships their version. Which means nobody ships the right thing.

One thing to try this week

Before your next piece of work kicks off — any work — write the out-of-scope list first.

Not what you're building. What you're explicitly not building.

Read it to the team. Watch what happens. That's your scope.

The argument you have now is cheaper than the one you'll have in week three.