scope-cuttinglisted

Cut scope by flipping the question. Instead of "How long will this take?" ask "How much time is this problem WORTH?" Set the appetite first, then shape the solution to fit. This is Shape Up's core insight: fixed time, variable scope. ## Set the Appetite Before touching scope, declare the time budget: - **Small batch:** 1-2 weeks for 1-2 people - **Big batch:** 6 weeks max for a small team If a project takes more than 6 weeks (or 3 weeks for 1-3 people per Linear's method), it's too big. Break it down or walk away. The appetite is NOT an estimate. An estimate says "this will take X." An appetite says "this is WORTH X." If the shaped solution doesn't fit the appetite, cut scope until it does — or kill the project. ## Scope Hammering For every item in the spec, ask these questions in order: 1. **Must-have or nice-to-have?** If the feature ships without it and users still get value, it's nice-to-have. Cut it. 2. **Shippable without it?** Can you deploy a working version that doesn't include this? If yes, cut it from v1. 3. **Edge case or core path?** If fewer than 20% of users will encounter this scenario, defer it. 4. **Compare to baseline.** The baseline is NO feature — not the ideal version. "Is this better than nothing?" always wins over "Is this as good as it could be?" ## Shape the Solution Down When scope is still too big after hammering: - **Cut breadth, not quality.** Support 1 auth provider well instead of 3 badly. Handle the happy path completely instead of