Glossary
What is a decision-ready demand?
A demand that can responsibly be committed to: the problem stated apart from the proposed solution, an intended outcome, a named owner, a first capacity figure, the dependencies, and the open questions written down as unknowns.
The point of the bar is where it sits — before the promise, not after. Most missed dates are decided at commitment time, when a request that had none of these became a promise anyway; readiness is checkable, optimism is not.
Decision-ready vs ready for development
Ready for development is a ticket-level question: can a team pick this item up in its next iteration without stalling? Decision-ready is a commitment-level question: can the organisation responsibly promise people, budget and a date for this demand? The two are often confused because both use the word ready, but they sit months apart and protect different things — one protects the sprint, the other protects the promise.
A demand can be decision-ready long before any ticket exists. And a perfectly refined ticket can belong to a demand that nobody ever decided on, which is how well-run teams end up delivering the wrong work on time.
Checking a demand against the bar
Ask six questions, and accept only written answers. Is the problem stated without the proposed solution? Would we recognise the intended outcome if we got it? Who is the one named owner? What capacity figure did the delivering team give — their number, not the requester's? What does the work depend on, and has the other party actually agreed? What do we not know yet?
A demand that fails a question has three honest routes. Close the gap, which is usually a conversation rather than a project. Send it to a time-boxed discovery if the gap is about whether the work is valuable or feasible at all. Or commit early anyway with a recorded exception naming why now, what is missing, who accepts the risk and what would change the decision.
Common mistakes
Accepting the requester's estimate as the capacity figure. Naming a team or a steering group as the owner, which means nobody. Reading an empty list of open questions as a sign of readiness, when it is more often a sign that nobody asked. And making the bar uncrossable — a bar with no exception route does not stop early commitments, it just moves them into meetings that leave no record.
Related terms
- Commitment exception — A recorded justification required to commit to work that is not yet decision-ready, naming why it is early, what is still unknown, who accepts the risk, and what condition would change the decision.
- Delivery governance — The practice of deciding what to commit to — establishing value, ownership, capacity, dependencies and open questions before people, budget or a date are promised.
- Delivery path — The level of rigor a demand takes to commitment — fast-track, standard plan, strategic initiative, or urgent exception — chosen at the decision step, so a small contained demand is not forced through the ceremony a strategic one needs.
This definition comes from building 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.
$189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself.