Definition of Ready

What is a Definition of Ready, what are differences to the Definition of Done and what are the benefits?

A list of criteria for Backlog Items

The Definition of Ready – also abbreviated as DoR – is a list of criteria that backlog items must meet before they can be scheduled in a sprint, e.g. as user stories. Examples of a Definition of Ready:

  • The backlog item is estimated and small enough to be implemented in a sprint.
  • The backlog item has at least one acceptance criterion.
  • The backlog item and the acceptance criteria are understood by all participants.
  • Possible external dependencies of the backlog item are eliminated.

The statement by Jeff Sutherland, co-founder of Scrum, is well known: “READY is when the team says: ‘Ah, we get it'”. Only if a backlog item has the status “Ready”, it may be included in a sprint.

Definition of Ready vs. Definition of Done

In contrast to the Definiton of Done, where the development team is responsible for compliance with the criteria, the Product Owner is responsible for the Definition of Ready. The idea is that only backlog items that comply with the DoR get into the sprint. In this context, the Conditions of Satisfaction are sometimes referred to.

Advantages of the Definition of Ready

In general, a definition of Ready is a useful tool because it provides

  • clarity and
  • transparency and
  • increases the understanding of those involved.

Beyond these advantages, information is documented and problems are avoided before they arise. A user story with external dependencies, for example, could jeopardize the sprint goal.

In particular, however, when using a Definition of Ready, organisations should ensure that it is not formulated too rigeros and thus hinders development. A DoR that, for example, demands:

“For every user story that refers to screens, there must be ready-made mock objects.”

would be such a – possibly unnecessary – restriction. The following wording would be better:

“For every user story that refers to important screens, there should be enough mock objects so that the team can clarify ambiguities in the running sprint.”

This would document appropriate preconditions, but the development team could work on the realisation of the user story.

We like to support you!

Software Development from Berlin