A definition of ready for commitments, not tickets

A definition of ready matters most at the level almost nobody applies it: the promise. Before a demand gets people and a date, it should clear a small fixed bar — the problem stated apart from the proposed solution, an outcome you could later check, one named owner, a capacity figure from the delivering team, the dependencies, and the unknowns written down. The verdict has three states, not two: ready, ready with conditions, or not ready. And when a real deadline forces a commitment past the bar, the crossing is recorded as an exception with a name on it — the bar bends visibly instead of breaking silently.

Definition of ready for commitments

Most engineering teams already have a definition of ready. It lives at the sprint level: a ticket is ready when it has acceptance criteria, a size, and no unresolved blockers. It is useful, it is cheap to check, and it governs almost nothing that matters — because by the time work is a ticket, the promise that will make or miss the date has already been made.

The gate is at the wrong door

Watch where a commitment is actually born. It is not born in refinement. It is born in a leadership call, a steering meeting, a customer escalation — the moment someone says "we can have that by end of Q3" and someone else writes it down. Everything after that is elaboration. The sprint definition of ready inspects the elaboration, item by item, with real rigour; the moment of promising is inspected by nobody. So teams pass work through an immaculate ticket gate while carrying commitments no gate ever saw.

What the promise-level bar checks

The bar for a promise is the bar for a decision-ready demand, and it has six checks:

The problem, stated apart from anyone's preferred solution.
An outcome written so you could later tell whether it happened.
One named person accountable for the decision.
A capacity figure the delivering team gave — not one produced for them.
The dependencies, including the cross-cutting ones nobody volunteers.
The open questions, written down as unknowns instead of quietly assumed.

Notice that none of these checks a ticket. All of them check whether the promise can be made honestly. A demand can fail every sprint-level criterion and still clear this bar, because the bar is not asking whether the work is specified — it is asking whether anyone should be putting people and a date behind it yet.

Three verdicts, not two

A binary gate gets argued around, because most real demands sit in the middle: broadly understood, one dependency unconfirmed, one question still open. Force the gatekeeper to call that "not ready" and the gate looks obstructive and loses its authority; let it pass as "ready" and the gate means nothing. The workable verdict set has three states — ready, ready with conditions, and not ready — and the middle one earns its place by naming the conditions. That converts an argument about the gate into a short list of work: confirm the dependency, get the figure from the team, answer the question. Usually days, not quarters.

When the date will not wait

A bar that cannot bend gets broken silently, because organisations have real deadlines — a regulator's date, a contract renewal, a promise already made on a stage. The honest mechanism is not to pretend otherwise; it is to make the crossing explicit. Committing a demand that has not cleared the bar costs a recorded exception naming four things: why it is being committed early, what evidence is still missing, who accepts the risk, and what condition would change the decision. A minute of writing. The bar bends visibly instead of breaking silently — and at quarter end, the exceptions are countable, which is how you learn whether your misses come from estimation or from the door.

A worked example

Meral runs payments engineering at a marketplace. Her sprint definition of ready is genuinely good — nothing enters a sprint without acceptance criteria and a size. On a Tuesday leadership call, the CFO asks for carrier invoicing by end of Q3, ahead of the accounting-system migration. The old reflex is "should be doable", plus a caveat that lives only in the room's short-term memory.

Against the promise-level bar, the demand fails two checks of six: no capacity figure from the team that would build it, and the settlement-file dependency on the ERP vendor is assumed, not confirmed. Verdict: ready with conditions — and the conditions turn out to be three days of work, not a process. The team sizes the work at roughly five FTE-months; the vendor confirms the file spec for August. Meral commits the following Monday, and the commitment carries evidence instead of optimism. Had the CFO needed the yes on the Tuesday, it would have cost the four recorded fields instead — and at quarter end, the difference between those two yeses would be visible in the record rather than in anyone's memory.

Keep it one bar, at one moment

The failure mode of any readiness idea is drift into ceremony: a template for every stage, a review board, a checklist that grows a row per incident. Resist it. The sprint-level check can stay exactly as it is — it protects sprints, and that is worth protecting. This is one additional bar, applied at one moment: when someone is about to put people and a date behind a request. Everything it checks is something the person making the promise should want to know anyway. A definition of ready that checks tickets protects a sprint. The one that checks promises protects your word.