Run quarterly planning with honest capacity, negotiated cross-team dependencies, and an explicit cut line that names what will not get done. Use when a team commits to a quarter of work and needs the plan to survive contact with reality.
Installs into .claude/skills of the current project.
Are you the author of Quarterly Planning?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/amey-thakur-quarterly-planning)
---
name: quarterly-planning
description: Run quarterly planning with honest capacity, negotiated cross-team dependencies, and an explicit cut line that names what will not get done. Use when a team commits to a quarter of work and needs the plan to survive contact with reality.
---
# 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 above the line is committed;
everything below is explicitly not this quarter. The line is the deliverable:
it makes the tradeoff a decision instead of a slow disappointment.
5. **Separate commitments from stretch and say which is which.** Commitments are
promises other teams can build on; stretch goals are what you attempt if
things go well. Labeling all of it "committed" destroys the word. Downstream
teams need to know which dates they can bet on.
6. **Write down what you are deliberately not doing.** A short "not this
quarter" list stops the same requests from reopening in week two and gives
you a clean answer when new work arrives: it goes below the line or something
above it moves.
## Checks
- Does planned work fit inside real available days, or inside a headcount
fantasy?
- Has every cross-team dependency been confirmed by the team you depend on?
- Can you point to the cut line and name what is above it and below it?
## Boundaries
This plans a quarter of delivery; it does not set the strategy or the annual
bets that decide what a quarter should even contain. Ceremony varies widely:
OKRs, sprint planning, and big-room planning are different wrappers on the same
honesty, so match your organization's format rather than importing another
team's ritual.