Records an MVP boundary with explicit in-scope capabilities, measurable acceptance criteria, deferred work, and non-goals so teams and AI agents do not expand scope by accident.
Package status: AI-assisted reference package. Static package validation has passed; implementation scenarios remain not run and human domain review is required before stable adoption.
Decision
Ship the smallest product slice that validates the core hypothesis while documenting what is explicitly out of scope. Every in-scope capability maps to a testable requirement with an owner. Deferred work carries a revisit trigger instead of becoming an implicit commitment. Non-goals are first-class so engineers and AI coding agents do not implement popular but unapproved features by default.
Scope
- In-scope user journeys, functional requirements, and acceptance criteria for the MVP release.
- Non-goals, deferred capabilities, and assumptions that bound design and implementation.
- Ownership of scope changes, including who approves additions after baseline sign-off.
- Traceability from requirements to verification artifacts used at merge time.
Outside this block
- Detailed technical architecture for post-MVP scale.
- Commercial pricing, legal terms, or compliance certification claims.
- Success metric formulas and instrumentation (see the companion success-metrics block).
Contract
- Each in-scope capability has a unique requirement ID, owner, and at least one externally verifiable acceptance criterion.
- Non-goals are listed explicitly; implementing a non-goal requires documented scope-change approval before merge.
- Deferred items include a revisit trigger such as a metric threshold, calendar date, or dependency resolution; they do not block MVP release by default.
- Scope documents distinguish user-visible behavior from internal implementation choices unless the latter is explicitly marked binding.
- AI agents and contributors treat this package as authoritative for feature inclusion; ambiguous requests default to out-of-scope until clarified.
- A scope diff is produced for every release candidate showing added, removed, or changed requirements since the last approved baseline.
Implementation guidance
- Store requirements in version-controlled markdown or YAML linked from the product repository.
- Tag issues and pull requests with requirement IDs to preserve traceability.
- Run a scope review each sprint; reject work that lacks a requirement ID unless filed as an approved change.
- Pair with success metrics so every north-star outcome maps to at least one in-scope journey.
Failure handling and safeguards
- If a critical defect forces a non-goal workaround, record a time-bounded exception with owner and removal plan.
- If stakeholders disagree on inclusion, escalate to the named scope owner rather than silently merging competing behaviors.
- If AI-generated plans propose out-of-scope features, halt implementation and request explicit scope amendment.
Verification and operations
- Measure scope churn: count of requirements added or removed after baseline per release.
- Track requirement coverage: percentage of in-scope IDs with linked passing verification evidence.
- Review non-goal violations in retrospectives; repeated violations trigger a scope baseline reset.
The executable-looking examples in this package are fixtures and acceptance contracts. Validate package structure before adoption; then implement and execute the scenarios in the target repository.
Adoption assumptions
- Names, dates, and numeric thresholds in
example.yamlare profile choices for a sample team-workspace MVP, not universal defaults. - The adopting team must map actors, market constraints, and regulatory boundaries to its domain.
References
- No external normative source is required; this package defines a product scoping decision.