Definition of Ready

Definition of Ready (DoR) is a concept within the Scrum framework that outlines the criteria necessary for a Backlog Item to be considered ready for implementation by the development team. It emerges from the collaborative understanding among Developers, the Product Owner, and Stakeholders regarding what is required to proceed with a Backlog Item. The importance of DoR lies in its potential to enhance clarity and alignment within agile teams, yet it also presents challenges, such as creating a false sense of readiness, neglecting the need for ongoing refinement, and leading to misconceptions about its equivalence with the Definition of Done (DoD). Unlike the DoD, which is an absolute measure of completion, the subjective nature of DoR can result in partial implementation, risking the integrity of the development process. To mitigate these issues, it is suggested that teams adopt a more nuanced approach to defining readiness, ensuring that each Backlog Item meets specific criteria, such as having a clear outcome, hypothesis, and telemetry for evaluation. The INVEST criteria further guide the formulation of Product Backlog Items, emphasising their independence, negotiability, value, estimability, size, and testability. Ultimately, a well-defined DoR fosters effective communication and understanding within agile teams, contributing to successful product development and organisational design.

Definition of Ready (DoR) is an artifact.

From the perspective of Scrum, the idea of Ready, as applied to a Backlog Item, represents everyone’s (Developers, Product Owner, & Stakeholders) understanding of what is needed to implement that Backlog Item. Since this is subjective and not objective, having a definition of what constitutes ready is not possible.

The danger of having a defined definition of Ready (DoR) is:

• False sense of Ready - First that it creates a false sense of Ready that encompasses the objective points that we can focus on, but misses the subjective. This can lead to false gating, where participants hold each other accountable for failing to achieve something that was not defined in the first place.
• Neglecting Refinement - If things are “ready” then why would we have to understand it better!
• False Equivalence with DoD - Using the DoR terminology generally leads participants to feel that the DoD and the DoR have an equivalence. This is dangerous as the DoD is an absolute boolean proposition, while the subjective nature of the DoR may lead it to be only partially implemented. If it’s OK to only partially achieve the DoR, the logical fallacy is that the DoD can also be partially implemented.

A solution that may enable the effective use of this practice may be to a different formula of naming to create disambiguation between the DoR and the DoD.

Backlog Candidacy Test

Every candidate Backlog Item should have:

• has a clear outcome or objective.
• contains a clear hypothesis.
• defignes clear telemetry to be collected.

Once candidacy is achieved then the Team & Stakehodlers can determin Ready with conversation.

Rule of Thumb

As a general rule Developers should not take Backlog Item into a Sprint that they do not fully understand and agree, as a team, that there is a reasonable likelihood of being successful.

INVEST

• I (Independent). The PBI should be self-contained and it should be possible to bring it into progress without a dependency upon another PBI or an external resource.
• N (Negotiable). A good PBI should leave room for discussion regarding its optimal implementation.
• V (Valuable). The value a PBI delivers to stakeholders should be clear.
• E (Estimable). A PBI must have a size relative to other PBIs.
• S (Small). PBIs should be small enough to estimate with reasonable accuracy and to plan into a time-box such as a Sprint.
• T (Testable). Each PBI should have clear acceptance criteria which allow its satisfaction to be tested.