Skip to content
← All terms

Glossary

What is a definition of ready?

The bar a piece of work must clear before it is accepted — applied at ticket level in Scrum, and far more consequentially at commitment level, before people and a date are promised.

At commitment level the bar is six things: the problem stated apart from the proposed solution, an intended outcome, a named owner, a capacity figure from the delivering team, the dependencies, and the open questions written down as unknowns. Readiness is checkable; optimism is not — and a demand that cannot clear the bar can still be committed, but only with a recorded exception.

Definition of ready vs definition of done

A definition of done is the bar at the exit: what must be true before work counts as finished — reviewed, tested, released. A definition of ready is the bar at the entrance: what must be true before work is accepted at all. Done protects the quality of what ships; ready protects the promise about when and whether it ships.

Many teams have a firm definition of done and no definition of ready, which is a common reason why quality holds up and dates do not. The work is built properly; it was simply promised before anyone knew what it was.

Ticket level vs commitment level

At ticket level the bar is about whether a team can start: the item is understood, small enough, and not blocked. It is sometimes criticised as a gate between teams, and at that altitude the criticism has a point — a ticket can be clarified in a conversation faster than it can be bounced back.

At commitment level the stakes are different. The question is whether an organisation should promise people and a date, and the costly misses are decided here, not in the sprint. The bar is the six things a promise needs: the problem apart from the solution, an intended outcome, a named owner, a capacity figure from the delivering team, the dependencies, and the open questions written down.

Introducing one without creating a bureaucracy

Start with those six items and nothing else, each answerable in a sentence. Allow the bar to be crossed early, but only with a recorded exception, so real deadlines are served without the gamble disappearing. Then, at the end of each quarter, compare the commitments that cleared the bar with the ones that crossed it by exception. If the ready ones do no better, the bar measures the wrong things; change it. What not to do is add an item every time something goes wrong — that is how a six-line bar becomes a form nobody fills in honestly.

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.
  • 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.

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.