Quarterly planning
Skill Amey-Thakur/AI-SKILLS/skills/big-tech-processes/quarterly-planning
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.From its SKILL.md
npx -y skills add Amey-Thakur/AI-SKILLS --skill quarterly-planningAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 22 days oldThe repository was created 22 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.0 KB, 611 tokens by cl100k_base, as published. Nobody here has run it
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
- 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.
- 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.
- 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."
- 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.
- 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.
- 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.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.