Scope is not something you argue about, it is something you choose together

In one line

If you harden the scope-judgment rules and the assumption ledger into files, you can answer a new request with "then what would you like to drop?" instead of "we can't".

Why this was needed

The scope you set in the first week of the engagement starts to leak from the second week. The places it leaks are always similar. The logistics team sends "just this one thing" on Slack, the corporate support team adds "while you're at it" at the end of a meeting, and we cannot find grounds for refusing on the spot. The agreement is in a drawer, and even when you read it, it is ambiguous whether this request falls under that sentence.

The second place is assumptions. You hear in the kickoff meeting that "the nightly batch runs only from 02:00 to 04:00" and set the maintenance window on that premise. Three weeks later you find out that assumption was wrong, but by then the schedule and the change plan are already stacked on top of it. If an assumption exists only in the meeting minutes, nobody checks it again.

The third place is the way you answer. If you answer an out-of-scope request with "that is not in scope", the conversation ends and the relationship suffers. From the customer's side, they asked because they needed it, and we are the people who came to help.

How it works

All three are fixed the same way — move the judgment from people's heads into files.

The scope rules are written as an ordered list. For each rule you write the condition, the result (in or out), and the reason, and you walk a request down from the top so that the first rule that matches wins. Because the order is the priority, you put the narrow rules on top and the broad rules below. If you put "work that touches personal data is out" at the very top, it is caught before the "warehouse system work is in" below it.

What matters here is deferring judgment. A request that no rule catches is not "out" but "not yet known". If you automatically push what was not caught to out, the gaps in the rules are never revealed. If you leave it as undecided, that list becomes the agenda for the next meeting.

In each verdict you also write which rule decided it. With this, when the customer asks "why is this not allowed?", you can just show one rule, and if the rule is wrong, you fix the rule. It becomes a conversation of fixing a file instead of persuading a person.

The assumption ledger records four things for each assumption.

전제      "야간 배치는 02:00 부터 04:00 까지만 돈다"
깨지면    점검 창이 배치와 겹쳐 서비스가 멈춘다
확인법    crontab 과 최근 30일 실행 로그의 시작 시각을 견준다
확인일    2026-08-20  (유효 14일 → 2026-09-03 까지)

Writing "what collapses if it breaks" is the heart of this ledger. When you write it down, it becomes clear that some assumptions cause nothing if they are wrong, while for others the whole plan sits on top of them. And you attach a validity period to the verification. The customer's environment changes even while we are watching, so something confirmed once cannot stay true forever. An assumption whose period has passed is not "wrong" but "needs to be checked again".

What it looks like in the field

First, hand over a trade-off table instead of a refusal. If the out-of-scope request is six days of work, you answer, "Adding this takes six days. If you drop these two of the currently agreed tasks, it fits. Which way would you like to go?" The customer has not been refused but has been given options, and usually they reset the priorities themselves.

There are two things to keep in mind when you hand over a trade-off table. The sum of the bundle you propose to drop must be at least the cost of the new request, and removing any one item from that bundle must make it fall short. If you propose dropping generously much more, the customer feels we are trying to reduce the work. And work that must be done (what the agreement nails down) is not put in the trade.

Second, do not hide the undecided list. If there are five undecided items, it means there are five gaps in the rules, and if you report that as it is, the customer helps fill them in. If you arbitrarily push an undecided item into in or out, that decision is one we made alone.

Third, write down the owner of the assumption. If it is written that the owner of "nightly batch time" is section chief Choi of the operations team, you do not have to wonder whom to ask when you check again. An assumption with no owner is never checked by anyone even after its verification period passes.

Fourth, hand over the rules and the ledger as deliverables. If all you hand over when the contract ends is a report, the next person starts over from the same place. The rules file and the assumption ledger become the starting point of the next contract as they are.

What really matters in practice

• The first rule that matches wins. The order is the priority, so put the narrow rules on top.
• What was not caught is undecided, not out. The undecided list shows the gaps in the rules.
• Write the result if it breaks, the validity period, and the owner together for each assumption.
• Answer an out-of-scope request with a trade-off table. Choose the bundle to drop so that it neither falls short nor overshoots.

What you will do in the next lab

You hold the kickoff package of (fictional) Taesung Foods. It is 25 requests, 10 agreed tasks, and six lines of the agreement that deal with scope. You write the scope rules as an ordered file, build a judge, and sort the requests into in, out, and undecided. The grader actually runs your judge with different rules and requests each time, checks the verdicts and the deciding rule, and also swaps the order of a narrow rule and a broad rule to see whether the priority is kept. Next you build the assumption ledger and a tool that finds the assumptions whose verification has expired. Finally, for a newly arrived out-of-scope request, you build a trade-off table and deliver it as a report.