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.
Scanned 9/5/2026
Install to Claude Code
npx -y skills add Amey-Thakur/AI-SKILLS --skill quarterly-planning --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Quarterly Planning?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/amey-thakur-quarterly-planning)More formats (shields.io, HTML) on the badges page.
---
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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!