Scoping is not estimating. The useful question is not how long the work will take, but how much time the problem is worth and what you will cut when the estimate turns out wrong. Fix the time, let the feature list move, write the tradeoffs down before any code exists, and make the first release the smallest thing that proves the operating model.
Why do software projects blow past their scope?
Because teams manage the average and get killed by the tail.
Bent Flyvbjerg and Alexander Budzier analyzed 1,471 IT projects for Harvard Business Review in 2011. The average cost overrun was 27 percent, which sounds survivable. The finding underneath it is not. One in six projects in the sample was what they call a black swan, with an average cost overrun of 200 percent and a schedule overrun of almost 70 percent. Their conclusion is the line worth pinning to the wall: "By focusing on averages instead of the more damaging outliers, most managers and consultants have been missing the real risk in doing IT."
That distribution changes what scoping is for. If overruns clustered neatly around 27 percent, the answer would be to pad the estimate and move on. They do not cluster. A minority of projects fail catastrophically, and padding does nothing for those, because the black swan is not a 27 percent miss with a bad week attached. It is a different kind of event.
So scoping is not an exercise in producing a more accurate number. It is an exercise in making sure the project cannot become a black swan. The output is not a better forecast. It is a smaller blast radius.
What is the difference between an appetite and an estimate?
An estimate answers "how long will this take?" An appetite answers "how much time is this problem worth?" Those two questions produce opposite behavior under pressure.
Ryan Singer's Shape Up, published free online by 37signals, puts the distinction in one line: "Estimates start with a design and end with a number. Appetites start with a number and end with a design." An estimate treats the feature list as fixed and lets the calendar move. An appetite treats the calendar as fixed and lets the feature list move.
Shape Up's appetites are concrete rather than aspirational. A small batch is work that one designer and one or two programmers can build in one or two weeks. A big batch is the same size team for six weeks. The six week figure is chosen deliberately: long enough, in Singer's words, "to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely."
You do not have to adopt Basecamp's process to use the idea. The transferable part is which variable you agree to hold still. A team that has decided a problem is worth six weeks has already made the hard call, and everything after that is negotiating what fits. A team that has agreed to a fixed feature list has not made a decision at all. It has deferred one. The deferral is what becomes the tail.
Write the tradeoffs down before you write the code
Malte Ubl's "Design Docs at Google", published in July 2020, is the most useful public description of what a scoping document is actually for. His framing starts from the job: "As software engineers our job is not to produce code per se, but rather to solve problems." The document exists to capture high level implementation strategy and key design decisions, with the emphasis on the tradeoffs. The value is catching problems early, while changes are still cheap.
The more useful half is where he tells you not to write one. "Writing design docs is overhead." Skip it when the solution is obvious, or when the document would be an implementation manual that never discusses a tradeoff.
That is a clean test, and it applies well beyond Google. A scoping document earns its cost when there is a real decision inside it. If the document contains no tradeoffs, it is a transcription of choices someone already made somewhere else, and it is waste. If it contains three genuine forks in the road and the reasoning for each, it is the cheapest artifact in the project.
There is a standing complaint in engineering communities that speaks to the same point. A list of software engineering "laws" that circulates periodically in communities like r/agile includes LeBlanc's Law, stated as "later equals never." It lands because "we'll fix that later" is how scope decisions get made without anyone deciding. One commenter's reaction to that list captures why it keeps resurfacing: "half of these you'll recognize from your own projects going sideways." Scoping is the moment to say, on purpose and in writing, what will never happen.
What actually belongs in the scope
A scope document that does this job is short. It answers seven things:
- The problem, in one paragraph of business language. Not a feature list. If it cannot be stated plainly, the software should wait.
- The appetite. How many weeks is this problem worth, decided before anyone designs a solution.
- Who touches the workflow: customer, operator, manager, admin, or vendor. Each one is a surface with its own requirements.
- The no-list. What you have explicitly decided not to build. This is the most valuable section and the one most often missing.
- The tradeoffs, and the reasoning behind each. Per the Google test, if this section is empty, the document is not needed.
- What "done" looks like, in terms someone outside the team can verify.
- The reversal cost. If this turns out to be the wrong build, what does it cost to undo, and who finds out first. Notice that none of those require knowing how long the work takes. That is the point. Six of the seven are decisions, and decisions are what bound the tail. The estimate is the least durable thing in the document.
Scope the smallest system that proves the model
The practical version of all this is that the first release should be the smallest thing that tests whether the operating model is real, not the smallest thing that technically ships.
Commerce Beacon scopes this way because the alternative is expensive in a specific direction. A broad first build commits the budget before the business has learned anything, which is precisely the shape of Flyvbjerg's black swan. A narrow first build costs less and teaches more, and it leaves the decision to expand in the hands of someone who now has evidence.
That lens sits behind SaaS platform development, where the work starts with the operating constraint and moves into architecture and integrations only once the constraint is understood. It is the same reasoning as the build versus buy question covered in custom software or more SaaS tools: the first job is to name the workflow, not to pick the technology. The Local Living project is an example of a scope that survived contact with reality because vendor onboarding, ordering, fulfillment, and admin review were understood as one workflow before any of them were built.
If the workflow cannot be explained clearly, the scope is not ready. Ambiguous scopes produce ambiguous products, and ambiguous products are where the 200 percent overruns live.
Common questions
Does scoping mean going back to waterfall?
No. Waterfall fixes the feature list and lets the schedule move, which is the failure mode described above. Scoping in this sense does the opposite: it fixes the time and treats the feature list as the thing you negotiate. The document is a page of decisions, not a specification of every screen.
How much time should scoping take?
Roughly the same order as the appetite it protects. A two week build does not deserve a two week scoping exercise. A six week build justifies a few days of writing down the problem, the no-list, and the tradeoffs. Ubl's rule applies: if the document has no tradeoffs in it, stop writing it and start building.