Agile 101: Acceptance Criteria vs. Definition of Done (DoD)

When I am teaching agile to new group of students, I find one of the biggest questions is: what does it mean to be “done?” And, what is the difference between Acceptance Criteria, and the Definition of Done (DoD)?

In agile, when someone says a user story is “done,” that means it needs no additional work, period. All the documentation is complete, it passed any required tests and certifications, passed validation checks, etc. It is “done” to the point that if the product was the ship tomorrow, there would be no more work necessary to complete or ship this user story. In waterfall, it is common to do the work or the activities of the user story or requirement but defer documentation and other activities till later. Being honest, there never is time “later,” as that time typically gets cannibalized for bug fixes, or even adding functionality before the deadline. Documentation, testing, etc. tends to get short-changed.

Agile has two different lists to ensure that the work is “done.” One is the Acceptance Criteria, and the second is the DoD. But the difference between the two is confusing for some that are just starting out. Especially those working in industries outside of software development.

The Acceptance Criteria are specific for the user story being implemented. For the work in the user story, what does it mean to be done? The definition of done does not change for user Stories. The DoD is the same over and over and over again. The DoD is a living document, and you may change or add items to it over time as the project evolves, but you do not adjust the DoD for the nuances of a single user story.

I think it’s best explained in an example. Imagine you are a car mechanic and you are going to perform an oil change. The Acceptance Criteria for an oil change:

• Is the filter is replaced?
• Has old oil has been drained and disposed?
• Does the car has the new oil filled?
• And is the cap is on tight!

The DoD doesn’t know if this is an oil change or head gasket repair; the same final verification steps would happen for the both. In this case, the DoD would be akin to:

• Documenting work performed, and explained to the customer
• Generate an invoice
• Have a peer do spot checks to ensure that your work was done appropriately.

As you hopefully see, the three steps of the DoD make no mention of gaskets, oil, etc. Any work performed with father of those three closeout steps. The closeout steps are what encapsulate the DoD.

If the mechanic then performs a tire rotation, the Acceptance Criteria would be different. That might look like:

• All lug nuts tightly fastened
• Tires are rotated
• Examine the tire tread depth and advise the customer

In the above, the DoD is the exact same for the oil change as it is for the tire rotation: Document, Invoice, and Spot checks.

Again, the Acceptance Criteria will differ greatly between user stories. The DoD remains consistent across all work, and across sprints. You may find that, over time, you may need additional DoD steps, like a test drive. That’s fine, the DoD can evolve. But it does not evolve or adjust for a single user story – it adjusts for all user stories going forward in perpetuity.

That’s it! They are simple ideas, but it can be confusing to those coming from Waterfall. I hope this helps you in your journey!

P.S. The Definition of Ready (DoR) differs greatly from the DoD, and I'll explain that in another post.