Topic
How to decide what to commit to
The short answer
Before committing to a piece of work, six things must be established: the problem as distinct from the solution someone already has in mind, the outcome, one named owner, a capacity figure the delivering team actually agreed to, the dependencies, and the open questions written down as unknowns. A request contains none of these; a commitment needs all six. Where a deadline forces an early commitment anyway, record why it is early, what is missing, who accepts the risk, and what would change the decision, so the exception is countable. And treat no and not-now as recorded decisions with an owner and a reason, never as the absence of one.
Almost every conversation about missed delivery dates starts in the wrong place. It starts in delivery — which sprint slipped, who was blocked, why the mid-point review didn't catch it — when the decision that produced the miss was made weeks earlier, at the moment a request turned into a commitment.
A request and a commitment are different objects. A request is someone wanting something: it has a requester and a desire and usually nothing else. A commitment is a promise made on behalf of other people's time. The gap between them is six things, and in most organisations there is no step where their absence becomes visible.
The three decisions this topic covers
What has to be true before you say yes. The problem stated as a problem rather than as somebody's preferred solution; the outcome, written so you could later tell whether it happened; one named owner; a capacity figure the delivering team gave rather than one produced for them; the dependencies, especially the cross-cutting ones nobody asks about; and the open questions, written down as unknowns instead of quietly assumed.
What to do when the date won't wait. Banning early commitments does not stop them, it hides them. The workable answer is to allow the exception and make it cost four recorded fields — why now, what is missing, who accepts, what would change it — so that at quarter end you can separate "we committed too early" from "our readiness bar is wrong". Those two have opposite fixes and are indistinguishable without the record.
What to do with the ones you will never build. A request left to rot in a backlog is a no that nobody communicated: the requester keeps asking, the team keeps re-reading it, and the reason evaporates. Park and decline should be first-class outcomes with an owner, a one-line reason, and — for a park — the condition that would unblock it.
The full argument
What has to be true before a request becomes a promise, and what to do with the ones that never should.
- When everything is a priority, run the capacity line
"It's all P1" is not a prioritisation failure — it is a missing constraint. What changes when priorities have to fit under a per-team capacity line.
- Sprint commitment vs forecast: the argument is at the wrong level
Scrum replaced sprint commitments with forecasts for good reasons. The organisation still needs commitments — one level up, where promises are made.
- OKRs point. Commitments deliver.
An OKR names a direction; it doesn't promise anyone anything specific. Why teams that run on OKRs alone still miss dates — and what fills the gap.
- The date sales already promised
The customer has the date, engineering has the surprise. How to take a pre-promised commitment without pretending it was your decision.
- A definition of ready for commitments, not tickets
A sprint definition of ready checks tickets. The one that matters checks promises — the bar a demand clears before people and a date are committed.
- The mid-quarter ask is an edit, not an addition
Capacity did not grow when the urgent ask arrived. A mid-quarter request is an edit to a named commitment — the honest record names what it displaces.
- You don't need a scoring framework
RICE and WSJF rank unshaped demands to two decimal places. A readiness bar plus a visible capacity line does the work the score pretends to do.
- What a decision-ready demand actually contains
Not a template — the six things that must be established before a request can honestly become a commitment, and how to tell when one is missing.
- What goes in the quarter, and who decides
Quarterly planning fails as arithmetic before politics: capacity treated as a total, and no record of what you are not doing.
- 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.
- Quarter planning without the theatre
A working quarter plan is a set of commitments the delivering teams agreed to — not a ranked wishlist. The meeting, the agenda, and what to stop doing.
- You will commit before you are ready. Make it cost four fields.
Banning early commitments does not stop them, it hides them. Recording them takes a minute and converts an invisible gamble into a named decision.
- Why delivery commitments slip before a single line of code
Most missed delivery dates are decided weeks before the work starts — when a request becomes a commitment without anyone checking it was ready.
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.