theAnirudhKumar Scope the Work
Most scope creep is not a client or a stakeholder changing their mind. It is a boundary that was never written down in the first place, so there was nothing to point back to when the request quietly grew.
The failure this exists to prevent: work that keeps absorbing "one more thing" because nobody ever said what was outside it, so every addition looks reasonable in isolation. That is not a discipline problem. It is a missing artifact, and it is written once, before the work starts, not re-litigated every time something new comes up.
What this needs
Minimum: what the work is and roughly what "finished" would look like. It will produce the in/out lists and the done condition from that, and mark what it had to assume.
Better with who asked for this and what they actually need it for, since the done condition is only honest if it matches what the request is for, not just what was said.
Best with a case where this same piece of work grew before, so the out list can name the specific thing that crept last time rather than a generic one.
Step 1: Name the actual ask, not the topic
"Redesign the onboarding flow" is a topic. "Cut onboarding drop-off by fixing the three screens where people are quitting" is an ask. A boundary drawn around a topic has no edge; a boundary drawn around a specific ask does. If the request as given is a topic, ask what the actual need behind it is before scoping it.
Step 2: Write the in list
What this piece of work actually covers, specific enough that someone could check a finished deliverable against it. Not aspirational, not everything that would be nice: only what this instance of the work commits to.
Step 3: Write the out list
The adjacent things a reasonable person might assume are included, named explicitly as not included. This is the list that does the real work later: when one of these comes up mid-project, it is not a surprise, it is something already named and set aside.
Step 4: Write the done condition
One sentence that is checkable, not a feeling. "Done" is not "it looks good" or "everyone's happy with it"; it is a condition someone else could verify without asking the person who did the work whether it counts.
Step 5: Name who moves the line
If something on the out list turns out to actually be necessary, someone has to be able to say so and move it into scope on purpose, rather than it sliding in unnoticed. Name that person or that role. Without this, the out list is decoration: everything eventually gets added because nobody was ever positioned to say no on the record.
Step 6: Output the boundary note
In list, out list, done condition, who moves the line. Short enough to reread in under a minute when something new comes up mid-work, because that is the moment it actually gets used.
Output
A filled boundary note: in, out, done, who decides changes. Not a project plan, not a timeline, not a full SOW.
Failure modes to watch for
An out list with nothing on it. If nothing was excluded, nothing was actually scoped, and the in list was probably written at topic level, not ask level. Go back to Step 1.
A done condition that only the requester can judge. "When it feels right" or "when they're happy" cannot be checked by anyone else and will not survive a disagreement later. Push for something a third party could verify.
Naming "we" as who moves the line. A boundary nobody specifically owns is a boundary nobody enforces. Name a person or a named role, not a group.
What this does not do
Decide who performs the work once it is scoped; that is delegate's job, working from this skill's own in list. Does not produce a formal statement of work, a contract, pricing, or legal terms; this is a working boundary for the person actually doing or overseeing the work, not a client-facing document. Does not estimate how long the work will take; a skill built for that is a separate concern from what the work covers.
Supporting files
assets/boundary-note.md- a one-page fill-in template: the ask, in, out, done condition, who moves the line.