DoR, DoD, & Acceptance Criteria

What's a DoR (Definition of Ready)?

Before we agree to take on new work, it's critical that we understand our customer's goal. A Definition of Ready is a check-list that reminds us what kinds of things to ask as we clarify the customer's expectations (without being specific to any particular customer goal; see Acceptance Criteria below for specific details related to a goal). As noted by Roman Pichler, the Definition of Ready is not a new concept in the Agile space. It has been further popularized and generalized by Kanban under the name of Explicit Policies. These policies can be used before we begin the work (Definition of Ready/Entrance Policy), as we move the work from one state to another or from one team to another, or when we consider the work done (Definition of Done / Exit Policy). These policies are often written at multiple levels; at varying levels of scope we have: Story, Iteration, Release. From a continuous improvement perspective, we have the policy we apply today, and the policy we aspire to reach some day. This may be represented as follows:

What's in a Definition of Ready?

We need a living document--something that is continuously updated as we learn better about our perimeter, that will prevent rework and unnecessary delays. While the list below is overkill for most teams, you may consider any of the following for your Definition of Ready:

  • Is the story INVEST-worthy (independent, negotiable, valuable, estimable, small, testable)?
  • Have we seen a demonstration of working code that proves any external components are complete and of high quality?
  • Are there any external files, media, recordings, images needed to complete this work?
  • Has the customer committed to time with us to explain the context and goals of the work?
  • Have relevant external teams committed time to support this work? (e.g., database staff, developers of external components)
  • Are we willing to defer elaboration of non-functional requirements, or do we have a clear idea of what they should be? (system load, multi-threading, permissions, robustness, etc.)
  • Do we know: who requested the work? when is it needed? what's a barely sufficient implementation?
  • Do we have the right skills to do this work?
  • Who can we ask for help if something goes wrong?
  • Are the acceptance criteria defined?
  • Do we have an estimate for this work?
  • Does the estimate match the customer's budget? Have we discussed the business value?
  • Has this been ranked in comparison to other backlog items, in terms of urgency, priority, effort, and value?
  • Do we have everything we'll need to meet the Definition of Done for this story if we complete it now?
  • Have we considered the downstream effects of releasing or testing this story?
  • Have we communicated about any ripple effects to other component teams?
  • Have we informed marketing/sales/business folk we're about to start this work?
  • Can we make these changes safely without breaking the current system? What if we have to abort this story early?
  • Do we know how this work fits in the larger context of the release plan or future product versions?

See also Ken Power's excellent blog entry on the Definition of Ready.

What's a DoD (Definition of Done)?

Before we consider our work done, we need to verify it using a standard at least as good as our downstream consumers will. A Definition of Done is a check-list that reminds us what these are. Note how the DoD here is more process-centric than the Acceptance Criteria in the next section. If we had the lofty goal of sending people to colonize Mars, our DoD for a launch would include:

Mars Spaceship Launch Definition of Done

  • All space craft components have passed unmanned tests in space.
  • All engineers have given thumbs-up for launch.
  • Science team has confirmed planetary alignment and asteroid activity provide a clear path.

What's Acceptance Criteria?

Acceptance Criteria are specific examples that illustrate the intended use of a problem, and may include notes about limitations of the solution. If we had the lofty goal of sending people to colonize Mars, our acceptance criteria would include:

Mars Spaceship Acceptance Criteria

  • The space capsule must fit 30 people.
  • The space craft is divided in at least two independent modules, so if life support fails in one, people can use the other.
  • Each capsule must have enough capacity to keep passengers alive during the 8-month transit and a 24-month wait on Mars.

Assumptions: automated robot crews will install living quarters and deliver supplies before the space craft arrives.