Define the smallest useful scope for your first system

A common scope problem in custom systems is not just “doing too much.” It is doing a little everywhere without making any complete process usable.

For example, the first release includes customer, inventory, order, commission and reporting pages, but staff still bridge every step with chats and spreadsheets. There are plenty of features, yet no part of the business can fully move to the new system.

A more useful first release completes one slice of the business, with a clear beginning and end.

Start with the problem, not the page

Instead of saying “We need a customer management page,” describe what happens today:

Customers arrive through links shared by different agents, and several people may contribute to a sale. At month-end, the team cannot reliably trace the original source or each person’s contribution, so commission settlement often involves manual disputes.

This describes the people affected, when the problem occurs and its consequences. It defines what the system should handle more effectively than a page list.

Six elements of a useful scope

Use this table to define the first release:

Element	Question
Trigger	What event starts the process?
Input	What information must the system receive?
Roles	Who reads, edits, confirms or approves?
Core rules	Which decisions must remain consistent?
End state	What marks this instance as complete?
Visible evidence	Which records demonstrate correct operation?

For the attribution example, the scope might be: a customer submits an enquiry through an identifiable link; the system records the source and subsequent participants; an authorised person confirms the sale; finance reviews the full record before settlement. The first release need not also handle property publishing, full accounting or payroll.

Separate “must have,” “later” and “outside the system”

Assign every requirement to one category:

Must have

Without it, the core process cannot finish or the result cannot be trusted. Examples include source links, customer records, participant records, sale confirmation and an audit trail.

Later

Useful work whose implementation can be informed by actual use after launch: advanced performance analysis, automatic lead allocation or complex commission simulations.

Outside the system

Work better handled by people or existing tools. For example, a manager can review occasional disputes instead of turning every dispute into an automated rule from the start.

Reducing scope should not quietly delete “later” items. Record why they are deferred and what evidence would justify reassessment.

Write testable acceptance scenarios

Feature names are hard to accept; business scenarios are easier. Use “Given–When–Then”:

Given a customer enquires through agent A’s dedicated link, when employee B follows up and eventually confirms the sale, then the system preserves the original source, subsequent participants, confirming person and time for authorised finance staff to review.

Add failure and permission scenarios:

• Unauthorised people cannot change source records.
• Changes to critical attribution preserve the original value, actor, time and reason.
• A duplicate customer prompts a warning rather than silently creating two identities.
• Unclear attribution goes to human review, not automatic commission allocation.

These scenarios support design, development, testing and business acceptance.

The first release also needs an operational plan

Finishing software does not mean the process is established. Scope should also explain:

• Whether historical data is migrated and the date range covered.
• Who trains staff.
• Who records and prioritises problems after launch.
• How work temporarily continues if the system is unavailable.
• Which measures show whether this process improved.

Without these arrangements, the technical boundary may be clear while the operational boundary remains undefined.

Confirm the first release on one page

An actionable first-release brief need not be long, but should include:

1. One business problem to solve.
2. The process’s beginning and end.
3. Roles and permissions.
4. Core rules that must be enforced.
5. Deferred and excluded work.
6. Three to five critical acceptance scenarios.
7. Results to observe after launch.

The scope is genuinely established when the business owner and delivery team can explain these seven points in the same way.

---

This article offers a general approach to system scope. Actual boundaries depend on business processes, risk and available resources.