[{"data":1,"prerenderedAt":287},["ShallowReactive",2],{"blog-\u002Fblog\u002Fhow-to-write-scope-in-and-scope-out":3,"blog-surround-\u002Fblog\u002Fhow-to-write-scope-in-and-scope-out":267,"blog-related-\u002Fblog\u002Fhow-to-write-scope-in-and-scope-out":276},{"id":4,"title":5,"audience":6,"body":10,"cluster":231,"date":232,"description":233,"draft":234,"extension":235,"factCheckedAt":236,"faq":237,"featured":234,"language":236,"meta":247,"navigation":248,"order":249,"originalAsset":236,"path":250,"pillar":251,"primaryKeyword":252,"relatedProject":253,"releaseScope":236,"reviewCycle":254,"reviewStatus":255,"reviewedBy":256,"searchIntent":257,"seo":258,"sources":236,"stem":259,"tags":260,"type":265,"updated":232,"__hash__":266},"blog\u002Fblog\u002Fhow-to-write-scope-in-and-scope-out.md","How to Write Scope In and Scope Out",[7,8,9],"engineering-manager","product-lead","business-analyst",{"type":11,"value":12,"toc":221},"minimark",[13,25,30,51,54,58,65,72,78,82,91,97,111,114,118,124,138,141,145,156,160,186,194,197],[14,15,16,20,21,24],"p",{},[17,18,19],"strong",{},"Scope defines what the work includes and — just as importantly — what it excludes."," The \"in scope\" list is the obvious half; the ",[17,22,23],{},"\"out of scope\" list is the one that actually protects you."," Scope creep and the \"but I assumed that was included\" argument almost always come from things that were never explicitly excluded. Anchor scope to the outcome, write both halves, and you've turned a fuzzy expectation into an agreed boundary.",[26,27,29],"h2",{"id":28},"in-scope-and-out-of-scope","In scope and out of scope",[31,32,33,40],"ul",{},[34,35,36,39],"li",{},[17,37,38],{},"In scope"," — what will be delivered. What the work includes.",[34,41,42,45,46,50],{},[17,43,44],{},"Out of scope"," — what will ",[47,48,49],"em",{},"not"," be delivered, stated explicitly. What the work excludes, even if it's reasonable, related, or someone assumed it.",[14,52,53],{},"Most scope documents write the first list and skip the second. That's exactly backwards: the second list is where the value is.",[26,55,57],{"id":56},"why-out-of-scope-is-the-half-that-matters","Why \"out of scope\" is the half that matters",[14,59,60,61,64],{},"If you only say what's ",[47,62,63],{},"in",", everyone fills the silence with their own assumptions — and every stakeholder assumes their reasonable-sounding extra is included. Then, mid-delivery, the requests arrive: \"and it'll handle the other entity too, right?\" You have nothing to point to, so you either absorb the creep or have an awkward fight.",[14,66,67,68,71],{},"An explicit out-of-scope list does three things: it makes the boundary visible, it forces the hard conversations ",[47,69,70],{},"early"," (when \"no, that's out\" is cheap), and it gives you a concrete reference when a new ask appears later.",[73,74,75],"pull-quote",{},[14,76,77],{},"Scope creep isn't caused by new requests. It's caused by boundaries that were never drawn — so every request looks like it was always included.",[26,79,81],{"id":80},"how-to-define-scope-from-the-outcome","How to define scope from the outcome",[14,83,84,85,90],{},"Scope falls out of the ",[86,87,89],"a",{"href":88},"\u002Fblog\u002Fhow-to-define-a-measurable-outcome","outcome",". The test for every candidate item is simple:",[92,93,94],"blockquote",{},[14,95,96],{},"Is this genuinely needed to reach the agreed outcome?",[31,98,99,105],{},[34,100,101,104],{},[17,102,103],{},"Yes"," → in scope.",[34,106,107,110],{},[17,108,109],{},"No"," → out of scope, at least for now — however reasonable it sounds.",[14,112,113],{},"This keeps scope tied to what actually matters and stops the drift toward \"while we're in there, let's also…\" that quietly doubles the work.",[26,115,117],{"id":116},"an-example","An example",[14,119,120,123],{},[17,121,122],{},"Outcome:"," \"Month-end exposure by entity is produced automatically and reconciles first time.\"",[31,125,126,132],{},[34,127,128,131],{},[17,129,130],{},"In scope:"," exposure by entity; the automated month-end feed; reconciliation to the source.",[34,133,134,137],{},[17,135,136],{},"Out of scope:"," exposure by counterparty (next phase); intraday\u002Freal-time exposure; currencies beyond the group's top five; a redesign of the underlying data model.",[14,139,140],{},"Now, when someone asks for counterparty exposure mid-build, it's not a fight — it's a scope change to be decided, because you already said it was out.",[26,142,144],{"id":143},"handling-scope-changes","Handling scope changes",[14,146,147,148,151,152,155],{},"Out-of-scope isn't \"never\" — it's \"not in this piece of work.\" When a genuine new need appears, treat it as a ",[17,149,150],{},"scope change",": name it, decide it explicitly (does it change the outcome, the date, the effort?), and either bring it in with eyes open or park it. What you're avoiding is scope changing by ",[47,153,154],{},"silent absorption",", where the boundary erodes one reasonable request at a time until the work is unrecognizable and late.",[26,157,159],{"id":158},"what-usually-goes-wrong","What usually goes wrong",[31,161,162,168,174,180],{},[34,163,164,167],{},[17,165,166],{},"No out-of-scope list."," Only \"in scope\" is written, so every assumption is \"in\" until proven otherwise.",[34,169,170,173],{},[17,171,172],{},"Gold-plating."," \"While we're here, let's also…\" — scope grows toward what's interesting, not what's needed.",[34,175,176,179],{},[17,177,178],{},"Scope by omission."," Boundaries that exist only in one person's head, so different people hold different scopes.",[34,181,182,185],{},[17,183,184],{},"Silent absorption."," New requests folded in without a decision, so the date slips and no one can say when it happened.",[14,187,188,189,193],{},"Write both halves, anchor them to the outcome, agree them with the requester and the team, and treat additions as decisions — and scope stops being the thing that quietly sinks the delivery. This is why ",[86,190,192],{"href":191},"\u002Fproducts\u002Fdelivery-sheet","Delivery Sheet"," makes scope-in and scope-out explicit fields: the boundary is drawn before the work starts, not argued about after.",[195,196],"hr",{},[14,198,199],{},[47,200,201,202,206,207,210,211,215,216,220],{},"Part of the ",[86,203,205],{"href":204},"\u002Ftopics\u002Ffinance-systems-delivery","Finance Systems Delivery guide",". See also ",[86,208,209],{"href":88},"defining a measurable outcome"," and the ",[86,212,214],{"href":213},"\u002Fblog\u002Fproject-intake-process-for-finance-and-engineering-teams","project intake process",". The ",[86,217,219],{"href":218},"\u002Fnewsletter","newsletter"," sends one finance-systems pattern, product decision or build lesson every two weeks.",{"title":222,"searchDepth":223,"depth":223,"links":224},"",2,[225,226,227,228,229,230],{"id":28,"depth":223,"text":29},{"id":56,"depth":223,"text":57},{"id":80,"depth":223,"text":81},{"id":116,"depth":223,"text":117},{"id":143,"depth":223,"text":144},{"id":158,"depth":223,"text":159},"intake","2026-07-23","Scope defines what work includes and — crucially — excludes. The 'out of scope' list is the half that prevents scope creep. How to define it from the outcome.",false,"md",null,[238,241,244],{"question":239,"answer":240},"What is scope in and scope out?","'Scope in' is what the work explicitly includes; 'scope out' is what it explicitly excludes. Writing both — especially the out-of-scope list — sets a clear boundary so everyone agrees on what will and won't be delivered. The out-of-scope half is what prevents scope creep and the 'but I assumed that was included' conversation later.",{"question":242,"answer":243},"Why is defining out-of-scope important?","Because scope creep and misaligned expectations usually come from things that were never explicitly excluded. If you only list what's in, people assume everything reasonable-sounding is also in. An explicit out-of-scope list makes the boundary visible, forces the hard conversations early, and gives you something concrete to point to when a new request arrives mid-delivery.",{"question":245,"answer":246},"How do you define project scope?","Anchor it to the outcome. Everything genuinely needed to reach the agreed outcome is in scope; everything else — however reasonable it sounds — is out, at least for now. Write both lists explicitly, get them agreed by the requester and the team, and treat later additions as scope changes to be decided, not silently absorbed.",{},true,4,"\u002Fblog\u002Fhow-to-write-scope-in-and-scope-out","finance-systems-delivery","project scope in scope out","delivery-sheet","annual","reviewed","Tan Gravam","informational",{"title":5,"description":233},"blog\u002Fhow-to-write-scope-in-and-scope-out",[261,262,263,264],"delivery","scope","requirements","finance-systems","text","z-MmPOrvGZ_W1YzlVCl6IE0JU5O376GTrruabNs5rMo",[268,272],{"title":269,"path":270,"stem":271,"type":265,"language":236,"draft":234,"children":-1},"How to Write Good Requirements for Finance Systems","\u002Fblog\u002Fhow-to-write-good-requirements-for-finance-systems","blog\u002Fhow-to-write-good-requirements-for-finance-systems",{"title":273,"path":274,"stem":275,"type":265,"language":236,"draft":234,"children":-1},"Hypercare and Post-Go-Live Stabilization","\u002Fblog\u002Fhypercare-and-post-go-live-stabilization","blog\u002Fhypercare-and-post-go-live-stabilization",[277,280,284],{"path":213,"title":278,"description":279},"Project Intake Process for Finance and Engineering Teams","How a team receives, shapes and decides on incoming work before committing people — the stages, the fields that matter, and four honest decisions.",{"path":281,"title":282,"description":283},"\u002Fblog\u002Fproblem-statements-vs-solution-requests","Problem Statements vs Solution Requests","A solution request tells you what to build; a problem statement tells you why. Converting solutions back to problems is the highest-leverage move in intake.",{"path":88,"title":285,"description":286},"How to Define a Measurable Outcome","A measurable outcome states what will be true when the work is done, in a way you can verify — a result, not an activity. How to write one, and the traps.",1785182340824]