Definition of Ready (DoR): Clarifying Criteria to Enable Effective Sprint Execution

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.