Defining In-Scope and Out-of-Scope Boundaries

Welcome back. Your recent discovery work has separated facts, assumptions, constraints, dependencies, risks, issues, and candidate requirements. That classification now enables a decision that is essential before detailed requirements multiply: what change is this initiative actually committing to deliver, and what is it explicitly not committing to deliver?

Clear boundaries are especially important in cross-functional work. A request such as “give employees claim visibility” can easily expand into changes to approvals, payroll processing, notifications, mobile apps, historical data, and reporting. Some of those may be valuable, but value alone does not place them in the current release.

By the end of this lesson, you will be able to write a concise, evidence-based scope statement with precise in-scope and out-of-scope boundaries, while keeping constraints, assumptions, and future ideas visible rather than silently absorbing them into the change.

---

Scope is an agreement, not a list of wishes

A scope boundary is the agreed limit of a proposed change. It tells stakeholders, delivery teams, and testers what outcome the team will deliver in the current initiative or release. It also provides a reference point when new requests appear later.

There are two related views:

• Product scope describes the capabilities, users, processes, data, and interfaces that the changed solution will cover.
• Work scope describes the activities and deliverables required to make that change real: analysis, design, configuration or development, testing, documentation, training, deployment support, and so on.

For a Technical or Business Analyst, product scope is usually the starting point. You clarify the business capability first, then work with delivery leads to identify the work needed to deliver it.

A good scope statement is neither too broad nor prematurely technical.

Weak wording	Why it fails	Stronger wording
“Improve claim processing.”	No one can tell which process steps or outcomes are included.	“Enable employees to view the current status of an existing expense claim without contacting Finance.”
“Create a status portal.”	States a possible solution but not the boundary of behavior, users, or data.	“Provide a browser-based claim-status view for active employees, using claim and payment-status data from existing systems.”
“Include notifications as needed.”	“As needed” is not a testable commitment.	“Email and push notifications are excluded from Release 1; the portal will provide on-demand status visibility.”
“Anything related to expenses.”	Invites uncontrolled expansion.	“Claim submission, approval-policy changes, and payment execution are excluded.”

The goal is not to predict every detail. It is to make the meaningful limits visible early enough for stakeholders to agree, challenge, or change them deliberately.

The article’s scope-of-work format is useful, but adapt it to the level of the change. A small enhancement may need one well-structured Confluence page rather than a large project document. What matters is that its boundaries are clear, reviewable, and traceable to the underlying business objective.

---

What belongs in scope, out of scope, and somewhere else?

A common error is to treat every statement as either “in scope” or “out of scope.” In practice, some statements belong in related registers.

Statement type	Example	Where it belongs
In-scope capability	Employees can view the status of their own submitted claims.	Scope statement and later requirements
Out-of-scope capability	The change will not modify payment execution in the payroll system.	Scope statement
Constraint	The organization’s existing identity provider must be used.	Constraint register, referenced by scope
Assumption	The current payroll interface can provide payment confirmation.	Assumption log, referenced by scope
Open point	It is not yet known whether managers need to view team claim status.	Open-points log until decided
Future candidate	A native mobile app may be considered after adoption data is reviewed.	Product backlog or roadmap, clearly marked as not committed
Existing issue	Claims with missing cost centres are failing today.	Issue log and candidate requirements

This distinction protects clarity. For example, “use the existing identity provider” does not mean that identity is automatically out of scope. The in-scope capability might be role-based access; use of the existing provider is the constraint that limits how the capability is implemented.

Similarly, an out-of-scope item is not necessarily unimportant. It may be deferred to a later release, owned by another team, prohibited by a constraint, or simply unrelated to the stated objective.

Scope dimensions to check

When defining a proposed change, test its boundary across several dimensions:

Dimension	Boundary question
Users and roles	Which users receive the capability? Which roles are excluded?
Business process	Which process steps change, and which remain unchanged?
Data	Which data is viewed, created, updated, or retained? What sensitive data must not be exposed?
Systems and interfaces	Which applications are changed or integrated? Which connected systems remain untouched?
Channels	Is the change available through web, mobile, email, API, or all of these?
Geography or business unit	Does the release cover one region, product line, customer segment, or the whole organization?
Release and time horizon	Is the item included now, deferred to a named later phase, or excluded entirely?
Delivery outputs	Are UAT support, operating procedures, training, or migration part of the delivered work?

This is similar to defining an interface boundary in systems work: consuming information from another system is not the same as changing its internal behavior. A status-visibility feature may read a payment confirmation but should not silently become a payroll-transformation initiative.

---

A practical test for every requested item

When someone asks for an additional feature, do not decide based only on enthusiasm or seniority. Assess it against the agreed change.

Use these five questions:

1. What business objective does it support?
   State the user or operational problem it addresses and the intended measurable outcome.

2. Is it necessary for the defined release outcome?
   A feature may be useful but not essential to achieve the committed outcome.

3. Does it fall within the stated users, process, data, systems, and release boundaries?
   Identify exactly which boundary it crosses, if any.

4. What evidence supports including it now?
   Look for policy, baseline data, stakeholder authority, user research, technical feasibility, or risk exposure.

5. If it is excluded, what is its disposition?
   Record whether it is deferred, transferred to another owner, blocked by a constraint, or rejected because it does not support the objective.

The final question matters. “Not in scope” should not become a polite way to lose an important stakeholder need.

---

Build a scope statement from discovery evidence

Use the following fictional but realistic case, continuing the expense-claim scenario from the previous lesson.

Proposed change

Employees frequently contact Finance to ask whether an expense claim is awaiting approval, under Finance review, rejected, or paid. Discovery indicates that status information exists across the expense-management and payroll systems, but is not visible to employees in one place.

The proposed change is claim-status visibility, not a full redesign of expenses or payroll.

A concise scope statement begins with an outcome-oriented summary:

Release 1 will enable active employees to view the current status of their submitted expense claims through a browser-based portal. The portal will present information received from the existing expense-management and payroll systems, reducing avoidable status enquiries to Finance.

That summary establishes the intended capability, the primary users, the channel, the systems involved, and the business rationale. It does not yet imply that every expenses-related feature belongs in the release.

Define the inclusions

Write inclusions as observable capabilities or committed delivery outputs. Avoid a vague list of department names or broad nouns such as “integration” and “dashboard.”

In scope for Release 1	Boundary made explicit
Employees can view the status of their own submitted expense claims.	Employee access is included; viewing other employees’ claims is not implied.
The portal displays submission, manager-approval, Finance-review, rejection, and payment-confirmation statuses.	Only defined status stages are included.
The portal reads claim-status information from the existing expense-management system and payment confirmation from payroll.	These source systems provide data; their internal workflows are not changed.
Access uses corporate sign-on and limits each employee to their own claims.	Authentication and authorization are part of the change.
The portal displays claim reference, submission date, current status, relevant decision date, and rejection reason where available.	The permitted data set is explicit.
Functional testing, UAT support, a short employee guide, and production-release documentation are delivered.	These are committed work outputs, not optional afterthoughts.

Notice that the list contains both product scope and work scope. A tester can use it to understand what needs verification; a stakeholder can use it to understand what will be available at release.

Define the exclusions

Exclusions should be as specific as inclusions. They should also be written in a way that prevents an excluded item from being mistaken for a hidden commitment.

Out of scope for Release 1	Reason or disposition
Creating, editing, cancelling, or resubmitting expense claims through the new portal	The release addresses visibility after submission, not claim management.
Changing approval thresholds, approver hierarchy, or Finance policy	These are separate policy and process decisions.
Executing reimbursements, changing payroll batch schedules, or altering payroll calculations	Payroll remains the payment-processing system.
Displaying employee bank-account details	Excluded by the data-minimisation and privacy boundary.
A native mobile application, push notifications, and automated email reminders	Potential future enhancement; not required for the browser-based visibility objective.
Historical migration of closed claims beyond the agreed retention period	Requires separate data-volume, privacy, and cost assessment.
Manager analytics and team-level claim reporting	A different user need requiring separate discovery and authorization analysis.

A strong exclusion does more than say “no.” It helps a stakeholder understand the boundary and, where appropriate, where the request should go next.

---

Make boundaries easy to review

A scope statement is useful only if stakeholders can review it without interpreting every line differently. The Project plan template below shows a helpful layout: it separates the problem statement from scope, distinguishes must-have and nice-to-have items, and provides a dedicated not-in-scope area alongside milestones and reference materials.

For analysis work, use a slightly more rigorous version of that layout:

Scope-document section	Minimum content
Problem and objective	Affected users, current pain point, desired measurable outcome
Scope summary	One or two sentences stating the release outcome
In scope	Capabilities, users, data, systems, process steps, and delivery outputs included
Out of scope	Explicitly excluded features, processes, data, channels, and systems
Constraints and assumptions	Linked IDs from the relevant registers, rather than duplicated text
Open points	Decisions still needed before the scope can be baselined
Approvals and version	Scope owner, reviewers, decision date, and document version

Be careful with “nice to have.” It can be useful during discovery, but it is not a final boundary. Before a release is committed, each nice-to-have item needs a clear status:

• included in the current release;
• deferred to a named future decision or release;
• transferred to another initiative; or
• excluded.

The next lesson will formalize prioritization. For now, do not let an uncommitted “nice to have” masquerade as a delivery promise.

---

Baseline scope, then manage requests deliberately

Once the relevant stakeholders approve the scope statement, it becomes a scope baseline: the current authoritative agreement about the change. It is not frozen forever, but it should not shift informally in chat messages, workshop notes, or verbal discussions.

When a new request appears, use a lightweight change-control routine:

1. Capture the request. Record who requested it, the stated problem, and supporting evidence.
2. Compare it with the baseline. Identify whether it is already covered, unclear, or outside the approved boundary.
3. Assess the impact. Consider affected requirements, processes, interfaces, data, risks, testing, and release commitments.
4. Obtain a decision. An authorized owner may approve it as a change, defer it, transfer it, or reject it with rationale.
5. Update the evidence. Revise the scope, backlog, assumptions, risk records, and stakeholder communications when the decision changes the baseline.

This is not bureaucracy for its own sake. It preserves trust. Stakeholders can request additional value, but delivery teams should not be expected to absorb additional work without a visible decision about its impact.

---

Key takeaways

A well-defined scope turns discovery evidence into a practical agreement about the proposed change.

• In scope identifies the capabilities and delivery outputs the team commits to provide.
• Out of scope identifies specific features, systems, process changes, data, or channels that the current change will not provide.
• Strong boundaries cover users, process steps, data, systems, channels, geography, release horizon, and delivery outputs.
• Constraints, assumptions, risks, issues, and open points support scope decisions, but should remain distinct records.
• Exclusions do not mean that a request lacks value; they clarify that it needs a later release, another owner, or a formal change decision.

Next, you will connect proposed requirements back to business objectives and measurable success indicators, so that each in-scope item has a clear reason for being included.