Scoping is the most underrated part of software delivery. Get it right and everything else gets easier. Get it wrong and no amount of engineering skill will save you.
The problem with vague briefs
Most projects start the same way: someone has an idea, they want it built, and the brief is something like "we need an app like Uber but for dog walking." That's a vision, not a scope.
When you start building without a proper scope, a few things reliably happen:
- Features creep in because "it would be nice to have"
- Deadlines slip because nobody agreed on what "done" means
- Budgets blow out because the original estimate was based on assumptions that turned out to be wrong
- Everyone gets frustrated — the client feels like they aren't getting what they asked for, and the team feels like the goalposts keep moving
A proper scoping process prevents all of this. It takes time upfront, but it saves multiples of that time later.
The three questions every brief must answer
Before writing a single line of code, get clear answers to these:
1. What problem are we solving?
Not "what feature do we want" — what problem does it solve? Features are solutions. Problems are what matter.
Bad: "We need a dashboard with real-time analytics."
Better: "Our operations team spends three hours every morning pulling data from four different tools to understand yesterday's performance. They need to see it in one place, instantly."
The second version tells you exactly what success looks like. You can now design the simplest thing that solves that problem — which is almost always cheaper and faster than the first version.
2. Who is it for?
Describe the actual human who will use this. Their technical ability, their context, their goals. A field engineer using your app on a mobile device in low connectivity is a different user than a CFO reviewing monthly reports on a desktop.
Getting this wrong is expensive. You will build the wrong thing.
3. What does "done" look like?
Define acceptance criteria before you build. For each major feature, write a sentence that starts with "A user can…" and completes with a specific, testable action.
"A user can log in with their email and password and land on the dashboard within 3 seconds."
That is testable. "Users should be able to access the system" is not.
Breaking a project into phases
One of the most common scoping mistakes is treating everything as Phase 1. In reality, not everything has equal priority or equal risk.
A useful exercise: for every feature on the list, ask two questions:
- How often will users actually use this?
- Can the product launch without it?
This gives you four buckets:
| Can't launch without | Can launch without | |
|---|---|---|
| High usage | Core — build first | High value — Phase 2 |
| Low usage | Investigate — is it really needed? | Nice to have — Phase 3+ |
Anything in the bottom-left quadrant deserves a hard conversation. "Can't launch without, but barely anyone will use it" usually means a hidden compliance requirement or a stakeholder assumption — both worth surfacing early.
Estimating honestly
Estimates are not promises. The earlier you are in a project, the wider your uncertainty band. A useful mental model:
- Day 1 estimate: ±50%. You're roughly calibrating whether this is a 2-week project or a 2-year project.
- After discovery and scoping: ±20%. You know the shape of the work.
- After detailed technical design: ±10%. You've broken it into tasks.
Share these ranges with clients. It sets realistic expectations and builds trust. Clients who understand uncertainty make better decisions — they're less likely to panic when scope changes, and more likely to make good trade-offs.
The one-pager scope document
Once you've done the discovery, distil everything into a single page:
- Problem statement — one paragraph
- Target users — two or three sentences
- Core features — bulleted list, each with acceptance criteria
- Out of scope — explicit list of what is NOT being built
- Open questions — things that still need decisions before build starts
- Rough effort estimate — with the uncertainty range
The "out of scope" section is as important as the feature list. It gives everyone permission to say "no, we agreed that's not in scope" without it feeling like a conflict.
Conclusion
Scoping is not bureaucracy. It is the most direct path to building the right thing, for the right people, at a predictable cost.
The projects that go badly are almost always the ones that skipped this step. The projects that go well are the ones where everyone agreed on what they were building before the first line of code was written.
Take the time to scope properly. Your future self — and your client — will thank you.