Scope boundaries: what is inside the work and what merely sits nearby

Scope boundaries are usually discussed as a matter of discipline: learn to say no, log every change, don’t quietly expand the work. The advice is correct and useless, because there is nothing to say no to — by the time the change is requested, the scope has been written in a way that makes the request look like a clarification rather than new work.

The break happens earlier, while the spec is being written. And it has a recognisable shape.

Scope described only from the inside

Take any spec you wrote this month and look for a sentence beginning with “not included”, “stays as it is” or “handled by a separate task”. Usually there is no such sentence.

That is what description from the inside means: everything the system will do is listed, and nothing is said about what it will not do. Formally the document is complete — every stated requirement is there. In practice it has no edge, and any question from outside lands in a grey area where the decision goes to whoever is loudest.

Why this is not pedantry. A boundary is not there to argue with the client, it is there for estimation. A developer estimates what they read; if an integration is sitting just outside the description, the estimate will be half the work — and the developer will not be the one who got it wrong.

Checking is easy. Read the spec and write down the questions it does not answer but anyone from an adjacent team would ask. More than three such questions means there is no boundary.

The unnoticed stakeholder

The second standard cause: a requirement is written from one side’s words, and a different side will be accepting it. A system usually has more stakeholders than there were people in the meeting where the task was discussed.

Here is an example that repeats from company to company. We are building time tracking. In the meeting: a department head and a couple of employees. They ask for something reasonable — log hours quickly, without extra fields, ideally all at once at the end of the week.

The spec is accepted, built and demonstrated. At which point the finance director appears, who needs those same hours as the basis for invoices: tied to a contract, with edits forbidden once the period is closed, and with a history of changes. None of these three requirements was in the spec — there had been nobody to state them.

What follows goes into the calendar as “an adjustment” and is in reality a rebuild of the data model. Logging hours retroactively and forbidding retroactive edits are mutually exclusive, and the choice between them had to be made before development, not after.

How to see it coming

The signs that only one side was consulted are visible in the text of the spec itself:

• Every requirement suits the same person. A real system is always inconvenient to somebody: control inconveniences the doer, flexibility inconveniences the controller. If nothing in the spec constrains anyone, you heard half the story.
• Nothing describes what happens to the data afterwards. Reporting, export, reconciliation, closing the period — those are the voices of the people who were not in the room.
• Nobody mentioned a retention period. A boring question, and revealing for that reason: it comes from whoever answers for the consequences, not for the data entry.

The practical move is not to get everyone into one room, which is rarely achievable. It is enough to walk the chain of data: who enters it, who reads it, who reconciles it, who answers if the number is wrong. That last question turns up the missing stakeholder almost every time.

What to put in the spec

A boundary is not a “constraints” section at the end of the document that nobody reads. It is a handful of specific statements, each of which can be disputed.

What sets the right-hand column apart is not detail but checkability. “No export to accounting” can be taken to the finance director and answered before development rather than after.

When the boundary has already been crossed

A request arriving mid-work almost never looks like new work. It looks like a clarification: “and also so the manager can see their own department”. One question tells the two apart — does anything change besides the screen.

1. A new role or a new permission appears. Not a clarification: the access model changes, and every check along with it.
2. A new state of the data appears. A closed period, a cancelled entry, a draft — each state multiplies the number of scenarios.
3. A second source of truth appears. The same hours now arrive from somewhere else, which means reconciliation, which is a separate piece of work.

If none of the three fires, then yes, it is a clarification and not worth arguing over. If any one of them does, the answer is not a refusal but a price: “this adds a role, so the access checks get rebuilt; let’s estimate it separately”. A conversation about dates goes down better than a conversation about who failed to write something down.

Write down what you turned away. Keep what did not make it into scope as a list inside the task: one line, a date, whose decision it was. A month later that list is the only evidence the question was discussed rather than missed. It also becomes the content of the next task.

What next

A described boundary gives you what a detailed description does not: something to check against. From here the requirement goes into development, where it has to be tied to code and tests so that a change to the spec does not get lost on the way. That is the subject of the piece on traceability.