The Difference Between Definition of Done & Definition of Ready

Elyse PlattWed, 04/03/2019 - 16:49
Subject

What is the difference between the Definition of Done (DoD) and the Definition of Ready (DoR) in Agile processes? Let's take a look at how to utilize these items.

Definition of Done (DoD)

I see the Definition of Done and Acceptance Criteria being commonly confused on teams. Acceptance Criteria applies to a specific work item while a DoD applies to the Increment, which is usually a collection of work items. The DoD tells us when the Increment can truly be considered “done.” In the technical realm, teams may to include activities such as passing of user acceptance testing (UAT), completion of system integration, and production installation in a DoD.

Do we have any readers who remember the residential cleaning service example from the Acceptance Criteria article? Let's add a DoD to this.

Work Item

Example Acceptance Criteria

Clean Living Room

1. Floor is free of dirt, debris, and pet hair

2. Blinds and curtains are free of dust

3. Throw blankets smell fresh and are folded on the couch

Other work items for the cleaning service may be to Clean Kitchen, Clean Bathroom, or Clean Bedrooms. Then, the DoD that applies to the Increment (the collection of all these work items) may include Cleaning Supplies Stored, All Lights Shut Off, and Doors Locked. How do we know when the Increment is done? It's “done” when all expectations set in the DoD are met.

Definition of Ready (DoR)

Just as we ask about whether an item actually “done” we also ask about whether an item is truly “ready.” Think of this as a policy in Kanban; that is, how do you know a work item is ready to be pulled into the system or, in Scrum, how do you know this item can be called “approved” or “ready” to pull into the Sprint? If you practice the refinement activity in Scrum, you are essentially following an informal DoR. In refining, teams add definition, acceptance criteria and effort (perhaps hours or effort points or #NoEstimates). The team then sets expectations that work cannot be pulled into the Sprint unless it has all the mentioned fields completed so that work does not begin until there is a clear definition of expectations. To practice this, explicitly document the conditions that must be met before work begins. A DoR keeps teams from starting work without first having a conversation and learning the customer's expectations.