How to define a project scope before the first sprint

To define a project scope, write down five things before any code: the business goal, who will use the product, the flows those users need with acceptance criteria for each, what is explicitly out of scope, and the constraints (budget, dates, integrations). Then agree on how changes will be handled, because they will come. A scope that fits on three or four pages and that both sides have read is worth more than a forty-page specification nobody opens after week one.

This guide is about software projects. It is the process we use at Nerdify before the first sprint of a new product.

Start with the problem and the goal

The first page of our scope documents says why the project exists, in the client's words. A sentence like "Our dispatchers retype every order from email into the warehouse system, and we want orders to arrive there on their own" tells the team more than a feature list does. When a decision comes up in week six that nobody anticipated, we go back to that sentence.

Then we write how the client will know it worked: a launch date, a number of users onboarded, a manual process that stops. Any of those works, as long as both sides can look at it after launch and agree on whether it happened.

List the users and what each one can do

Next come the roles. Most business software has more of them than the first conversation suggests: the customer, the staff member, the admin, someone in finance who only needs reports, sometimes an outside partner. Each role gets one line about who they are and a list of what they can and can't do.

This list does two jobs. It shows the size of the permission system, which is often a larger piece of work than any single screen. And it surfaces people the client forgot, such as the support person who needs to see a customer's account without being able to change it.

Describe the flows, not the screens

We describe the product as flows: a sequence of steps a user goes through to get something done. "A player searches games near them, picks one, pays, and gets a confirmation email" is a flow. It covers several screens, an integration with a payment provider and an email, and it can be tested from start to end.

Each flow gets acceptance criteria: statements someone can check with a yes or no. For the booking flow, for example:

• A player can only book a game that has open spots.
• Payment is taken before the spot is confirmed.
• If payment fails, the spot is released and the player sees why.
• The facility sees the booking in its admin within a minute.

Acceptance criteria are where most of the real scoping happens. Writing "payment is taken before the spot is confirmed" forces a conversation about refunds, failed cards and two players booking the last spot at the same time, and it is far cheaper to have that conversation now than in week eight.

Write down what is out of scope

We consider the out-of-scope list the most useful section in the document. Everything the client mentioned that won't be in this phase goes here, by name: the mobile app, the second language, the integration with the accounting system, the reporting dashboard.

Those items can still come in a later phase. Listing them keeps anyone from being surprised at the demo. When a client reads "Mobile app: out of scope for this phase, the web app will be responsive" and agrees, the question of whether the mobile app was included is settled before it can turn into a dispute.

Name the constraints and assumptions

Constraints are the fixed points the project has to work around, such as a launch date tied to a season or an event, a budget ceiling, an existing system the new one must read from, or hosting rules from the client's IT team. Each one changes how we plan, so we want them all on the table early.

Assumptions are the things we are taking as true without having verified them. "The payment provider supports split payments to facilities." "The client provides the copy and the logo." "The existing database can be exported to CSV." Every assumption is a risk, and listing them lets the client confirm them or tell us we are wrong. When we can't confirm an important assumption, we turn it into the first task: a short spike to check the API, the export or the data before the plan depends on it.

Prioritize inside the scope

Even a well-defined scope usually contains more than the budget or the date allows. We sort every flow into must-have for launch, should-have if time allows, and later. The must-have list should describe a product someone could use on day one, even if it is smaller than the client hoped.

This sorting is where the client makes the real trade-offs, and it is better done with the full list in front of them than one feature at a time during development.

Writing the acceptance criteria forces the conversations that would otherwise happen in week eight.

Turn it into an estimate

With flows, roles and constraints written down, we can estimate. We estimate each flow as a range rather than a single number, and the width of the range says how much we still don't know. A flow we have built many times, like sign-up with email verification, gets a narrow range. An integration with a system we haven't seen gets a wide one, and often a spike before the estimate is final.

Small projects start at $5,000, and the price grows with the scope and the size of the team that builds it. That is one more reason to write the scope before asking for a price.

Agree on how changes are handled

Scope changes are normal. The client learns something from the first demo, a competitor launches a feature, a user interview changes priorities. What causes trouble is changes that arrive in a chat message and get built without anyone adjusting the plan.

Any change goes into a short written request, we estimate it, and the client decides whether it replaces something in the current scope, gets added with more time or budget, or waits. Clients often choose to swap once they see the trade-off in writing.

Our scope template

This is the outline we start from. The finished document is usually three to five pages.

Who should be in the room

We build the scope over a few working sessions. On the client side, we need the person who can make decisions about priorities and budget, and someone who knows the day-to-day work the software will support. They are often not the same person. On our side, the engineer who will lead the build is in every session, because the questions an engineer asks ("what happens if the payment succeeds but the email fails?") are the ones that keep the scope honest.

When both sides sign off, the scope becomes the plan for the first sprint. It will change, and the change process above is how it changes without anyone losing track of what was agreed.

If you have a product idea and want help turning it into a scope and a plan, our product development team runs this process with you before any code is written.