Scope

Scope exists because the same request produces different pictures in different heads. Someone says "let's add coupons," and an engineer pictures one input field on the checkout screen while a salesperson pictures an admin console where a customer can create and hand out codes. Both are using the phrase "coupon feature," so nothing in the meeting reveals that they disagree.

The mismatch surfaces in the estimate first. Asked how long it will take, one person says two weeks and another says six. Neither of them is bad at estimating; the amount of work each had in mind differed by a factor of three. Start building in that state and week four brings the sentence "I assumed that part was included."

So teams stopped settling this in conversation and gave it a field in a document instead. In a PRD, that field is not there to record the name of a feature but to pin down how far the name reaches. With the boundary written out, estimates come from the same picture, and when requests pile up later there is something to compare them against — you can point at the moment the work grew.

Scope holds in two layers: a list and a depth. You write out what will be built as items, then attach a phrase to each item saying how far it goes. A list on its own does not draw a boundary.

Coupons split up like this.

1. The included list. Add a coupon code field to the checkout screen, check whether the entered code is valid, apply the discount to the order total. Three lines.
2. The depth of each item. Only fixed-amount discounts are handled; codes are issued by the operations team writing rows into the database directly this time. Without those two lines, whether percentage discounts and an admin issuing screen are in or out varies from reader to reader.
3. The explicit exclusions. The field where you write down what you have decided not to build is called out of scope. One line saying automatic coupons are not part of this release ends the discussion in five minutes when it comes up three weeks later.

Once the boundary is set, three things are tied together: the amount to build, the time it takes, and the people on it. Move one and one of the other two has to move. Asking for the same amount in less time is asking for more people; asking for less time with the same people is asking for less work. Pin all three at once and the only thing left with any give is quality, so the team starts skipping tests or dropping the error cases. Grow the coupon list from three lines to five while the two weeks stay fixed, and what actually gets cut is deciding what the screen shows when a code is wrong.

None of this makes the boundary permanent. It makes changing it a step you take on purpose. A new request goes through an edit to the field rather than straight into the build, and once the field changes the time and the staffing get another look. Requests that accumulate without that step are what people mean by scope creep.

Four moments send people to this field.

1. Estimating before a build starts. Engineers read it before answering how long anything takes. When it's empty, what comes back is not a duration but a question, and if there's no room to ask the question, the answer tends to assume the largest version.
2. Breaking the work into pieces. Turning one item into a single sentence from the user's side produces a user story, and those sentences are the units engineers pick up. A story that has no corresponding item in scope gets caught right there.
3. Starting design. The number of screens to draw comes out of this field. One input box or a full admin console is the difference between two days and two weeks on Noa's calendar.
4. Talking to customers. Sofia checks this field and the exclusions before answering a customer. The exclusions are what she opens first, because that is the only place recording what not to say yet. Skip the check and somebody promises a thing the team has explicitly deferred.

Pagedeck's coupon work went exactly that way. The field Mia wrote first said only "coupon code entry and discount application," and Theo came back with two questions after reading it: are percentage discounts handled, and is the issuing screen part of this. Adding two lines took ten minutes, and the estimate that came out afterward was two weeks rather than six. Four weeks of growth got cut by two sentences.

"Is this in scope? I don't see it in the document."

The request isn't on the agreed list, so it should go through a decision instead of straight into the build.

"Let's narrow the scope. Push the admin screen to next time and ship the input field first."

Cut the amount of work to protect the date.

"With scope this wide, two weeks doesn't work. Which part do you want to drop?"

The amount and the time don't match, so one of them has to give.

These lines land in a fixed order at a kickoff. Grace asks when it will be done, Mia reads out the list, and Theo answers with a duration based on the list he just heard. Reverse that order — fix the date first — and the list gets trimmed in conversation rather than in the document, which leaves the original list sitting there. Whoever opens the file three weeks later reads the version from before the trim.

The frequent reading is that scope is a promise you can't revise. It's written down and several people agreed to it, so it looks that way. But the point of the field is not to prevent change; it is to make change visible. When you learn something new, revising is the right move, and the date gets revisited along with it. Treat it as unchangeable and the team stops editing the document and starts quietly adding work instead, which puts you back where nobody can say what grew. Quiet additions are the expensive kind, because none of them triggers a second look at the date.

The other common belief is that a wide boundary is the safe one, since anything that comes up later can be called included. But a wide list is the same as no boundary: it can't carry an estimate and it doesn't say what to build first. A loosely written line becomes the evidence behind "that was always included" three weeks on, and the person saying it is never the person who has to build it. At that point the document works as a shield rather than as a record of what was agreed.