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.
- What goes in the quarter, and who decides
Quarterly planning fails in a predictable way: capacity is treated as a total, priorities are treated as a ranking, and neither survives contact with the first escalation.
- 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.
- 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.
- 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 decision with a name on it.
- Why delivery commitments slip before a single line of code
Most missed delivery dates are decided weeks before the work starts — at the moment a request becomes a commitment without anyone checking whether 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.