Scope and acceptance criteria

Scope Control & Acceptance Criteria

Use this skill to shape work items, guard against silent scope expansion during planning and implementation, and define objective completion criteria so tasks finish cleanly instead of drifting into endless polish.

Workflow

1. Establish a fixed appetite and explicit boundaries (Shape Up):
   • Clarify the problem boundary and constraints before detailed implementation begins.
   • Partition every task into three explicit buckets:
     • Must-Have Core: Required for the primary user flow to work end-to-end with proper authorization, validation, data integrity, and error handling.
     • Deferrable Enhancements (Nice-to-Have): Convenience features, secondary bulk operations, extra configuration knobs, or cosmetic polish that can ship in a follow-up if needed.
     • Out of Scope (No-Gos): Adjacent features, unrelated refactors, or speculative platformization explicitly excluded from this task.
2. Write testable, finite acceptance criteria:
   • Express acceptance criteria as observable behaviors and invariants, not open-ended aspirations (replace "make the dashboard fast and flexible" with "dashboard loads the 30-day workspace summary in one query and filters by date range").
   • Ensure developers have room to choose the simplest implementation details that satisfy the acceptance criteria.
3. Detect and intercept scope creep early:
   • Watch for classic scope-creep vectors during design and coding:
     • Turning a single-purpose feature into a generic plugin/rule engine.
     • Adding admin UIs or settings screens for parameters that change once a year via config.
     • Bundling unrelated codebase-wide cleanup or style migrations into a feature branch.
     • Gold-plating edge cases that cannot occur given upstream validation.
   • When scope changes are proposed mid-task, surface the concrete impact on delivery time, complexity, test surface, and risk before expanding the work item.
4. Record deferred items with explicit revisit triggers:
   • Never drop deferred ideas into a vague backlog abyss, and never build them "just in case".
   • Document each deferred item with:
     • Why it is deferred now (e.g., single-provider support satisfies current requirements).
     • Trigger to revisit (e.g., "Revisit when a second payment provider is approved for onboarding" or "Revisit when table exceeds 500k rows").

Anti-Patterns to Avoid

• Treating every review comment as mandatory scope expansion: Distinguish blocking correctness gaps from optional follow-up ideas.
• Reopening settled scope decisions without new evidence: Once a trade-off is accepted, help execute within that boundary unless new technical or product facts emerge.