scope-the-worklisted

# 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