How to scope a software project before anyone writes code

Ask five people what a project is for and you will get five answers, all reasonable. Scoping is not the act of writing those five answers down. It is the act of choosing one of them and being able to say, out loud, what the other four cost.

That distinction matters because scope is where a build is actually decided. By the time anyone is writing code, the interesting choices have already been made. If they were made badly, no amount of engineering discipline afterwards recovers the schedule.

A scope is a decision, not a document

The most common artefact handed to us is a list of features. It is usually thorough, often the product of several meetings, and almost never a scope. A list of features says what someone would like. A scope says what is being built first, what is being built later, and what is not being built at all.

The test is simple. Take the document and try to remove something. If there is no principle in it that tells you what to remove, it is a wish list. A scope contains its own instructions for shrinking, because it will need to shrink.

The question that replaces the requirements list

Instead of asking what the system should do, ask which single job is being done badly today, and what it currently costs. That question is harder to answer and far more useful, because it produces a number rather than a paragraph.

In practice the answers cluster into three kinds: something takes too many hours, something is wrong too often, or something cannot be answered at all. Each points at a different first build, and each has a natural stopping point that a feature list does not.

The one-week rule, and where it comes from

This is not a preference we invented. DORA, which has run the longest continuous research programme on software delivery, publishes working in small batches as a named capability, and its guidance is unusually blunt about size: any batch of code that takes longer than a week to complete and check is too big. Its recommended increments are hours to a couple of days.

DORA also states plainly that working in small batches predicts both software delivery performance and organisational performance. That is the useful part for scoping. Batch size is not a taste question that developers happen to care about, it is one of the few variables with a measured relationship to whether things arrive.

So the rule we use is not a promise about speed. It is a constraint on scope: if the first useful version cannot be described as something checkable within about a week, the scope is still too wide and the conversation is not finished.

A scope you cannot check in a week is not a plan. It is a hope with a deadline attached.

What to cut, in order

When a scope has to come down, the order matters, because cutting the wrong thing produces something that technically ships and helps nobody. Ours goes:

• Roles. Build for the one person who feels the pain daily. Admin panels for users who do not exist yet are the cheapest thing to defer and the most commonly kept.
• Edge cases. Handle the ninety per cent path properly and let the rest go to a human for now. A queue of exceptions is a feature, not a failure.
• Integrations. Every connected system doubles the number of things that can be someone else's fault. Export a file first, integrate once the thing is proven worth integrating.
• Configurability. Options are how a team avoids making a decision. Hard-code the decision, and pay for flexibility only when two real users genuinely differ.

Notice what is not on that list: correctness, and the part the user touches every day. Those are the two places where cutting is a false economy, because the thing quietly stops being used and nobody files a complaint about it.

The four things a scope has to name

A scope we would actually build against fits on one page and names four things. Anything else is commentary.

• The one job being done, in a sentence a non-technical person would recognise.
• Who does it, by name or by role, and where they are standing when they do it.
• What proves it worked, expressed as something observable rather than a feeling.
• What is explicitly out, listed, so that adding it later is a visible decision and not a drift.

The fourth is the one people skip and the one that does the work. A scope without a written exclusion list has no defence against the perfectly reasonable request that arrives in week two.

Where scoping actually goes wrong

Rarely in the technology. We have written before about how training centres end up running enrolment, attendance and certificates in spreadsheets, and the pattern there is the pattern everywhere: the useful version dies waiting for the complete one, because someone asked for a parent portal before attendance worked at all.

The second failure is ownership. If nobody can approve a cut, no cut happens, and the scope grows by consensus until it cannot be delivered. This is not a software problem and it is not unique to software. BDG Labs makes the same argument about sales, that a thin pipeline is usually an undefined process rather than a lack of effort. Same disease, different department.

What we do instead of an estimate

We quote in days, and the reason is a scoping reason rather than a pricing one. A system scoped to a week has to be about the actual bottleneck, because there is no room in a week for anything decorative. The constraint does the editing that a meeting would not.

If you want to see how that plays out end to end, our process page walks through it, and what we build is the honest list of shapes this applies to. The system finder is a faster way to get to the same answer if you would rather not talk to anyone yet.

An honest limit

Small batches do not make a badly chosen project succeed. If the one job is the wrong job, shipping it in a week only means finding out sooner, which is genuinely valuable but is not the same as being right. Scoping tightly is a way to reduce the cost of being wrong, not a method for being correct.

There is also a category of work where this advice does not apply cleanly: anything with a regulatory or safety surface, where the ninety per cent path is not an acceptable first version. If that is your situation, the scoping conversation is a different one, and anybody who tells you otherwise on a discovery call is selling.

If you are scoping something this week

Write one sentence naming the job. Write the name of the person who does it. Write what you would look at to know it worked. Then write the list of things you are deliberately not building, and get someone to disagree with it while it is still cheap.

If that page cannot be filled in, the project is not ready to be estimated, and any number you are given is a guess wearing a suit.