What goes in the quarter, and who decides
· 8 min read · by Tan Gravam
The short answer
Plan a quarter against per-team capacity rather than an organisational total, commit to fewer things than the total allows, and write down what you are explicitly NOT doing — the list of declined and parked work is what makes the plan hold when the first escalation arrives. Rank by what the organisation is trying to change rather than by requester seniority, and treat the plan as a set of individually recorded commitments rather than one slide, so that adding something mid-quarter forces the question of what it displaces.
Quarterly planning has a shape that repeats almost everywhere. A list is assembled. Someone totals the capacity. The list is trimmed until the two numbers meet. Everyone agrees, and within three weeks the plan is a historical document that people reference ironically.
Three things go wrong, and they are all arithmetic before they are politics.
1. Capacity is not a total
"We have 40 FTE-months this quarter" is a sentence that cannot be acted on. The constraint is never the organisation, it is the specific team every plan happens to need — and totalling across teams hides exactly that.
Four demands each needing a little from the data team can be comfortably inside the organisational total while being impossible for the data team. The total says yes; the only team that matters says no; and nobody finds out until week seven, because the plan was validated against the wrong number.
Plan per team, and the impossible ones surface at planning time, which is the whole point of planning. Cross-cutting groups — security, legal, design, privacy — need this most and get it least, because no single demand's plan mentions them prominently enough to notice.
2. Commit to less than fits
A plan filled to capacity is a plan with no capacity for the quarter's actual events: the incident, the departure, the customer escalation that turns out to be real.
There is no clever way around this. Either you leave room deliberately, or the room gets taken from whatever was least defended — usually the work with no loud stakeholder, which is usually the platform and reliability work you will miss in six months.
The uncomfortable version: committing to 70% of capacity and delivering all of it is a better quarter than committing to 100% and delivering 75%, even though the second one "did more". The first produced promises that held. Delivery organisations are trusted on the ratio, not the volume.
3. Write down what you are not doing
This is the one most plans skip, and it is the one that makes the plan survive.
A quarter plan that lists only the yeses is defenceless. When something new arrives in week four — and it will — the conversation is "can we fit this in", which has no principled answer, so the answer is decided by whoever is most senior in the room.
A plan that also lists what was declined and parked, with reasons, changes the conversation to "what does this displace". That question has an answer, it is answerable by the people in the room, and it makes the cost visible before the decision instead of after it. Recording the noes is covered in its own piece — this is where the payoff shows up.
Ranking: by what changes, not by who asked
Most prioritisation schemes are elaborate ways of not saying that the ranking follows requester seniority. Scores get built, weights get argued, and the output matches what the loudest stakeholder wanted, because the inputs were supplied by the people with an interest in the output.
A more honest starting question: what is the organisation trying to be different about by the end of this quarter? Rank against that. Demands that serve it go first regardless of who asked; demands that serve nothing on the list are candidates for a clear no, not for the bottom of a backlog where they will rot.
This does not remove politics. It relocates the argument to where it belongs — what the organisation is trying to change — instead of hiding it inside a weighted score that nobody believes.
Each commitment on that list also needs one named person accountable for it , or the ranking has nobody to defend it in week four.
The plan is a set of commitments, not a slide
The deepest structural problem: a quarter plan is usually one artifact, so it can be edited silently. Something gets added, the slide is updated, and no record exists that a promise was changed.
Treat the plan as what it actually is — a set of individual commitments, each with an owner, a size the delivering team agreed to, and a date. Then adding something mid-quarter is not an edit, it is a new commitment that has to displace a named existing one. The forcing function is structural rather than moral, which is the only kind that survives a determined VP.
How DeliverySheet handles it
Commitments are recorded per demand with capacity agreed per team, not as an organisational pool — the total is derived from the per-craft rows rather than typed, so a plan cannot claim a total its own breakdown does not support. Each commitment carries a quarter, a year and a target date, and re-baselining a commitment re-agrees capacity per team rather than adjusting a number centrally.
The declined and parked work stays visible as its own inbox buckets rather than disappearing, and committing something that is not ready requires the four-field exception — which then appears in an Early commitments report, so at quarter end you can ask whether the misses came from committing early or from a readiness bar set wrong.
What it deliberately does not have: a weighted priority score. Configurable prioritisation is on the roadmap, and I would rather ship it after watching real quarters than invent a formula that dresses seniority up as arithmetic.
I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.
$10/month per workspace during the launch period (normally $189), unlimited members, 7-day free trial. I answer the support email myself.
More on deciding what to commit to
Read the overview: How to decide what to commit to →
- Saying no is a decision. Record it like one.
Most requests that never get built were never actually declined — they were left to rot in a backlog. That costs more than a clear no.
- An owner is a person, not a team
A team name in the owner field means the decision has no address - and the failure shows up at exactly the moment a judgement call is needed.
- What a decision-ready demand actually contains
Not a template to fill in — the six things that have to be established before a request can honestly become a commitment, and how to tell when one is missing.