Most agile teams have heard of Definition of Ready and Definition of Done. Yet in many organizations, both have become little more than checklists. Teams debate which items should be included, whether they are mandatory and how strictly they should be applied. Surprisingly little attention is given to why these mechanisms exist in the first place.
Recently, while exploring testing as a form of assessment, I started to view DoR and DoD differently. An assessment needs two things: a reference model that defines what good looks like, and evidence that allows us to judge whether those expectations have been met. Viewed through this lens, DoR and DoD appear to serve complementary purposes.
Definition of Ready is not merely a planning tool. It helps determine whether the reference model is sufficiently mature for work to begin responsibly. Are the requirements clear enough? Are the intended outcomes understood? Have important business rules, assumptions, constraints and quality expectations been made visible? Is there enough shared understanding to make implementation a reasonable next step?
This does not mean that everything must be known in advance. A rigid DoR can become a gate that delays learning and encourages teams to over-specify work before they have had a chance to explore it. Readiness should not mean certainty. It means that the team understands what good looks like well enough to begin, while recognizing what still needs to be learned.
Definition of Done serves a related but different purpose. It describes the state that work must reach before it can be considered complete. That may include conditions the product must satisfy, such as updated documentation or the absence of critical defects. It may also include practices that strengthen confidence in the conclusion, such as code review, automated testing, security analysis or demonstration.
These are not merely procedural tasks. They either contribute to the required state of the product or generate evidence that the required state has been achieved.
DoD therefore helps answer two questions:
- Has the work reached the expected level of quality?
- And is there sufficient evidence to support that conclusion?
This creates an interesting symmetry:
DoR protects the quality of the criteria. DoD protects the quality of the conclusion.
Without a meaningful DoR, teams risk building against an incomplete or poorly shared understanding of success.
Without a meaningful DoD, teams risk declaring success without reaching the required state or producing enough evidence to justify the claim.
Perhaps the real purpose of DoR and DoD is therefore not process compliance. They safeguard the two foundations of assessment: a sufficiently trustworthy reference model and a sufficiently trustworthy conclusion.
Seen this way, they are not administrative artifacts. They are quality mechanisms.
Leave a Reply