The short answer
To define the scope of a software project, start with the operational problem, not with a list of screens. A good scope describes the goal, who uses the system, the routines it covers, the business rules, the integrations, what is left out, and how each delivery will be accepted. All of it in writing, reviewed with the people who run the process and approved by the person who decides.
You do not need to arrive with this ready. Turning an operational problem into a validated scope is part of the developer's job, and it usually happens in a study phase before any larger commitment. What helps a lot is being able to explain what takes effort today, causes delays or leads to errors, and who feels that problem day to day.
What a good software scope contains
Scope is not a list of features. It is the agreement on what the system needs to solve and how far it goes. Seven parts show up in any scope that holds up:
- Goal. The problem the system solves, stated in one or two sentences, and how you will know it has been solved. "End the double data entry between reception and service" guides decisions; "modernize the process" guides none.
- Users and roles. Who uses it, how often and with what permissions. A system like Ágil Cidadão, our citizen service system, has three roles (citizen, service agent and management), and each one uses the same information in a different way.
- Routines covered. The processes the system follows from start to finish, described as they actually happen: who starts them, where they go, where they end. This is where the exceptions nobody remembered in the first conversation come up.
- Business rules. The conditions the system must respect: deadlines, approvals, calculations, who can do what. A rule that only exists in someone's head becomes a defect once the system goes live.
- Integrations. Which systems the new one needs to talk to, in which direction and through which means, such as an API or a structured export. It is worth confirming early what each system allows, because integrations are where surprises usually live.
- Exclusions. What is not part of this stage, written as clearly as what is. The list of what is left out prevents a good share of the mid-project arguments.
- Acceptance criteria. How each delivery will be considered done. A sentence like "the service agent can open the request on behalf of the citizen and the history records author and date" can be tested; "work well" cannot.
Some requirements belong in the scope even if nobody asks for them: how many people use the system at the same time, what personal data it stores and what Brazil's data protection law (LGPD) requires about that data, and whether there are accessibility requirements. Leaving this for the end tends to be expensive, because it affects the whole design.
Checklist to review the scope before hiring
Before approving a scope, whether your team wrote it or a vendor delivered it, check that it answers these questions:
- Is the problem written down? You can read the goal and understand why the system exists without knowing the project.
- Did the people who run the process take part? The routines were described by the people who carry out the process, not only by those who manage it.
- Is every role listed? With what each one can view, create, approve and delete.
- Do the rules have an owner? Each business rule has someone on your side who confirms it is correct.
- Were the integrations checked? For each existing system, it is known what it allows and who is responsible for it.
- Is there a list of what is left out? If there is not, each person will assume a different boundary.
- Do the items have acceptance criteria? Each delivery states how it will be tested and approved.
- Is the essential separated from the nice to have? The scope shows what goes into the first version and what comes later.
- Are data and migration planned? If there is information in spreadsheets or in an old system, the scope says what will be migrated and how.
If several answers are "I don't know", that does not mean the project is bad. It means more study is needed before estimating. We explain that phase in what product discovery is.
How to prioritize what is essential now and what can wait
Every scope starts bigger than it needs to be. Each department brings its own list, and adding up all the lists is the shortest path to a long project that takes a while to deliver value.
The question that sets priorities is simple: without this, does the main routine work? If the answer is no, the item goes in now. If the routine works, even with some manual effort, the item can move to a later stage.
- Essential now. What solves the main pain and what is mandatory by law or for security, such as access control and personal data protection.
- Important, but it can wait. Additional reports, convenience automations, screens for roles that rarely use the system.
- Nice to have. Ideas that make sense but that real use still needs to confirm.
A lean first version, focused on the routine that suffers most, goes into use while the rest is being built. What the team learns from using it changes the list of what comes next, almost always for the better. The reasoning is the same as for a well-defined MVP.
Fixed scope or evolving scope: which to choose
There are two ways to handle scope in a contract, and both work when applied to the right case.
| Criterion | Fixed scope | Evolving scope |
|---|---|---|
| When it fits | A clear problem, with a beginning, middle and end | A product that will change with use |
| What is defined at the start | All deliveries and their acceptance criteria | The goal, the first version and the priorities |
| How it handles change | Each change is assessed and approved separately | Priorities are reviewed every sprint |
| Predictability | Schedule and investment defined from the start | A predictable pace, with scope adjusted by what is learned |
| Main risk | Locking in early something that use would have shown differently | Losing focus if nobody decides what is left out |
We work with both models, fixed-scope project and dedicated team, and we recommend one of them after understanding the case. In both, change is part of the process: we assess the impact of each request on schedule and effort, show the options, and nothing changes without the approval of whoever hired us.
In the Brazilian public sector, Law 14.133/2021 (the public procurement law) requires a preliminary technical study and a terms of reference before contracting, and those documents already play part of the role of the scope. The more the terms of reference describe the problem and the acceptance criteria, and the less they read like a list of screens, the more room is left for the right solution.
Common mistakes when defining the scope of a system
- Starting with the screens. Designing the interface before understanding the routine leads to a good-looking system that does not fit the work.
- Listening only to managers. Those who decide know the goal; those who operate know the exceptions. A scope without both views fails on one of them.
- Copying the old system. Reproducing screen by screen what exists today carries along the workarounds the team created to get around its limitations.
- Leaving integrations for later. Finding out mid-project that the other system has no API changes the schedule and sometimes the solution itself.
- Using vague terms. "Intuitive", "fast" and "complete" cannot be tested. Each one needs to become an acceptance criterion.
- Not writing down what is left out. Silence turns into expectation, and unmet expectation turns into conflict at the end of the project.
How the scope becomes a schedule
Once the scope is approved, each item becomes an entry in the backlog, the prioritized list of what will be built. Large items are broken into parts that fit in a sprint, and each part gets its own acceptance criterion.
The schedule comes from combining three things: the size of each item, the order of priority and the dependencies, such as the integration that must exist before the report that uses its data. Design, development and infrastructure overlap, so the schedule is not a queue. We cover what weighs most on the timeline in how long it takes to develop a custom system.
In our way of working, scope, assumptions, risks and schedule are recorded at the kickoff meeting, and the scope is formally approved before design. After that, each sprint starts with priority planning and ends with a demo of what was built. That is how, in custom software development, the written agreement becomes a system in use.