qarium goga-define-scope
Purpose
Define the boundaries of the product change.
Transform the established problem, goals, requirements, and constraints into a clear statement of:
- what is included in the current solution;
- what is explicitly excluded;
- what should not be solved as part of this change.
The result must protect the product work from scope creep while ensuring that everything necessary to solve the identified problem remains inside the scope.
Contract
consume:
- product
- problem
- goals
- requirements
- constraints
produce:
- scope
Core Principle
Scope is a boundary, not a feature list.
The central question is:
What must be part of this product change to solve the problem, and what deliberately remains outside it?
Scope must be derived from the problem and goals.
Do not define scope based on what happens to be technically convenient or interesting.
Product Interview
Scope boundaries are product decisions.
Do not infer what belongs in or out of scope solely from implementation convenience.
Interview the user when the boundary between the current change and adjacent functionality is materially ambiguous.
Clarify when necessary:
- which user scenarios are part of the current change;
- which related scenarios should remain unchanged;
- whether an adjacent workflow should be modified;
- what is intentionally deferred;
- what the minimum complete solution is.
Do not automatically include related functionality merely because it would be convenient to change it at the same time.
Process
1. Define the required scope
Identify everything that is necessary to solve the problem and achieve the established goals.
Consider:
- essential user scenarios;
- required product behaviour;
- required states;
- necessary user roles;
- necessary supporting behaviour;
- constraints that require additional product behaviour.
If removing something would prevent the product from solving the problem, it belongs in scope.
2. Define the excluded scope
Identify functionality that may appear related but is not necessary for the current problem.
Common examples:
- future enhancements;
- additional user segments;
- unrelated workflow improvements;
- advanced customization;
- reporting or analytics not required by the goals;
- integrations that are not necessary for the current solution;
- optimizations that do not affect the defined outcome.
Explicitly exclude these when they are likely to become sources of scope creep.
3. Protect the core problem
Check that scope remains centered on the original problem.
Ask:
- Does everything in scope contribute to solving the problem?
- Is any functionality included simply because it is convenient?
- Are we solving adjacent problems that were not identified?
- Are we adding capabilities because they might be useful later?
- Would removing this item prevent achievement of the goals?
If an item does not contribute materially to the current goals, challenge its inclusion.
4. Check completeness
Scope must contain everything necessary to deliver the agreed user experience.
Compare:
Problem
↓
Goals
↓
Requirements
↓
Scope
Verify that the scope does not accidentally exclude a requirement that is necessary for the solution.
5. Check constraints
Ensure that the scope can be implemented while respecting established constraints.
A scope decision must not silently invalidate a constraint.
If the goals cannot be achieved within the current constraints and scope, report a conflict.
6. Handle adjacent concerns
When the problem touches an adjacent product area, determine whether that area is actually required for the current solution.
Do not automatically expand the scope because another part of the product is involved.
Ask:
Is changing this area necessary to solve the current problem, or merely a potentially better future improvement?
Only the former belongs in scope.
Scope Structure
Produce two explicit boundaries:
scope:
in:
- ...
out:
- ...
in
Items that are necessary for the current product change.
out
Items that are intentionally excluded from the current product change.
Do not use out as a backlog of future features. Include an item only when its exclusion is relevant to preventing ambiguity or scope creep.
Scope Quality
A good scope is:
Focused
Centered on the identified problem.
Complete
Contains everything necessary to achieve the goals.
Explicit
Leaves important boundaries unambiguous.
Defensible
Every included item can be justified by the product context.
Limited
Does not expand into unrelated improvements.
Challenge the Scope
Challenge both inclusion and exclusion.
If both inclusion and exclusion are reasonable interpretations and they would materially change the product outcome, ask the user to choose.
Do not resolve scope boundaries through assumption.
Challenge in
Ask:
- Is this necessary?
- Which goal or requirement requires it?
- Is it solving the current problem?
- Could it be removed without affecting the intended outcome?
Challenge out
Ask:
- Is this actually unnecessary?
- Does excluding it break an important user scenario?
- Does a requirement implicitly depend on it?
- Are we excluding it only because it is inconvenient?
Do not use scope to hide unresolved product decisions.
Conflict Detection
Report a conflict when:
- an in-scope item contradicts a constraint;
- an out-of-scope item is required to achieve a goal;
- the scope excludes a necessary requirement;
- the scope includes functionality unrelated to the problem and its inclusion creates a conflicting goal or requirement;
- the requested solution cannot achieve the goals within the defined scope.
Example:
conflict: |
The current scope excludes the administrative workflow,
but the requirements require administrators to configure
the behaviour before users can use the feature.
reason: |
The excluded workflow is necessary for the defined product
behaviour to function.
The orchestrator will invoke goga-define-resolve.
Do not resolve cross-context conflicts yourself.
Missing Information
Ask the user only when a scope decision materially affects the product outcome and cannot be derived from the existing context.
Valid questions may concern:
- which users are included;
- which scenarios are required;
- whether an adjacent workflow is part of the current change;
- whether a particular capability is necessary for the core outcome.
Do not ask about technical implementation.
Do Not Define
This skill must not define:
- technical implementation;
- architecture;
- project tasks;
- development estimates;
- release planning;
- technology choices;
- future product roadmap.
Scope is about product boundaries, not engineering planning.
Output
Produce:
scope:
in:
- ...
out:
- ...
The result must clearly establish the boundaries of the current product change.
The final scope must be broad enough to solve the problem completely and narrow enough to prevent unrelated work from entering the PRD.