quarterly-planninglisted

# Quarterly planning Quarterly planning turns ambition into a set of commitments a team can actually keep. It fails in a predictable way: capacity is counted as if everyone codes five days a week, dependencies are assumed rather than agreed, and every proposed item is marked "must" so nothing is ever cut until it slips. A real plan is honest about how much fits and explicit about what does not. ## Method 1. **Start capacity from real available days, not headcount.** Take the calendar, subtract holidays, planned leave, on-call rotations, interviews, and a standing tax for support and keeping the lights on. A six-person team rarely has six people of new work; plan against the number that remains after the known drains. 2. **Size work in ranges and discount your optimism.** Estimate each item as a band, not a point, and apply a haircut to the total because teams systematically underestimate. If last quarter you planned twelve items and finished eight, plan eight this time. History beats hope. 3. **Negotiate every cross-team dependency in writing, both directions.** For each thing you need from another team, get their owner to agree to the scope and the date, and confirm what they need from you. An assumed dependency is a first-week surprise. "Platform confirms the API by week 3" beats "assuming platform is ready." 4. **Rank the full list and draw the cut line.** Force a stack rank, then draw a visible line where capacity runs out. Everything abov