feature-scopinglisted

# Feature Scoping ## The Law ``` A FEATURE ESTIMATED WITHOUT A WRITTEN SCOPE IS A COMMITMENT MADE AGAINST UNKNOWN WORK. "Give me a rough number" produces a number that becomes a deadline before the scope is understood. Written scope → time estimate against that scope → explicit commit IS a feature decision. ``` ## When to Use Trigger before: - Any request for an engineering estimate - Any sprint planning that includes new functionality - Any stakeholder conversation that will produce a commitment - Any handoff from product to engineering ## When NOT to Use - Time-boxed spikes where the output is knowledge, not a feature (the scope is "spend N days and report back") - Hotfixes with unambiguous scope (the scope is "fix the specific bug described in the issue") ## The Scope Document A scope document answers four questions before any estimate is given. ### 1 — What is being built? User-visible behaviour only. Not implementation details. ``` The user can: - [Action 1] — e.g., "filter search results by date range" - [Action 2] — e.g., "export the filtered results as CSV" The system will: - [Behaviour 1] — e.g., "persist filter state across sessions" ``` ### 2 — What is NOT being built in this scope? Name the exclusions. Every implicit exclusion is a future dispute. ``` NOT included in this scope: - [Exclusion 1] — e.g., "bulk export (> 1000 rows)" - [Exclusion 2] — e.g., "real-time filter updates without page reload" ``` ### 3 — What are the acceptance criteria? Sp