When it comes to building things, we often want to know when it's really done. Two terms have gained popularity over the last couple of years within the realms of software development and other areas that use spillover ideas from the agile movement. These two concepts are acceptance criteria and the definition of done. Unfortunately those concepts are often mixed up which leads to subpar results.
The distinction can be pretty short: the definition of done (DoD) is a property of a process-step, while acceptance criteria are properties of a request for a capability. However, the question remains: why does it matter?
Let’s clarify some terms
I intentionally used the uncommon way to refer to a requirement as “a request for a capability“ to avoid notions such as story, requirement, feature, epic etc. Sometimes just saying what we actually mean instead of using an overused metaphor can make things much clearer. For now I will call “requests for a capability” simply work items, since that term has –at least up until now– very few connotations.
Where does the definition of done come from, and what does it mean?
To be perfectly honest I don't exactly know where the phrase came from. (I'll come back to Scrum in the postscriptum below) I've heard jokes about “If it works on your machine, you're about 80% done” and “do you mean done, or do you mean done done“ since the 80s. So obviously it's not really a new phenomenon that it's hard to tell when something really is done.
The term became more formalized, especially in the Scrum community between 2005 and 2011, when “Definition of done” became a top-level topic with it’s own heading in the scrum-guide. In this context the definition of done is the sum of all quality requirements a work item has to fullfil to be considered “done.”
If we look at it from a process perspective, this is a policy all work items have to comply with before they can move from “working on it” to “done.”
Who brought us acceptance criteria, and why?
Again, the origins are lost in the depth of time. At least to me. But the first experiences I had with them as a part of agile software development were back in my earlier XP-days, around the turn of the century.
At that time it was “common practice” (at the places I was around) to put requirements on cards. And when the time came to find the answer to “how would you know that this item was done” with the onsite customer, we just flipped over the card and jotted his acceptance criteria on the back of the card.
Those acceptance criteria hardly ever included anything technical, let alone any requirements regarding the documentation or in which source code repository it should reside. Those things were captured by our working agreements. In a section that nowadays would be called definition of done.
The acceptance criteria usually were things the customer would be able to do with the system once the requirement had been implemented. Someting like: “I can see the list of all unbooked rooms in an area when I search by zip code“ as one acceptance criterion for a card called “find available rooms” in a booking system.
Remember that these were the days of real on-site customers in a high trust environment and stories were written according to the CCC idea of Card – Conversation – Confirmation. Therefore it was quite okay to have such a vague acceptance criterion, where there was no up-front definition of what a “search by zip-code” actually means or how the “unbooked rooms” state had to be determined.
Nowadays these acceptance criteria are sometimes formulated as BDD or ATDD style scenarios and examples, wich allows for very concrete and specific acceptance criteria (but without enforcing them).
Now, what is the difference between acceptance criteria and the definition of done?
After we defined the terms, the terse explanation from above “the definition of done (DoD) is a property of a process-step while acceptance criteria are properties of a request for a capability” might actually make sense.
So, the «defintion of done» is a rule that applies to all the work items in the system and is a policy on a very specific edge between two columns on a board, namely the edge separating the “done” column from the one right before it. In contrast, «acceptance criteria» give the answer to the question “what functionality does the system have to provide to consider this work-item to conform to the customers expectations?”
And so, both are necessary and neither is a replacement for the other. Acceptance critery go with work items, and the definition of done goes with the system.
till next time
Michael Mahlberg
P.S. In most real life settings, processes tend to have more policies than just the definition of done.
And some of them describe the expections at process boundaries. If you use the Kanban method to model these processes you would naturally make these policies explicit as well, like I described in an earlier post.
P.P.S.: Scrum didn't start of with the now prominent Definition of Done as a first class citizen.
In the original books, that used to be literally required reading for aspiring scrum masters in 2005 –Agile Software Development With Scrum[ASD] and Agile Project Management with Scrum [APM]– there is “Done” on the same level as “Burndown”,“Iteration”,“Chicken” and “Pig" [APM, p141] and no notion of "Definition of Done" in either of the books.
Even in the Scrum Guide from 2010 –one year before the DoD moved up and got its own headline– there are paragraphs like
If everyone doesn’t know what the definition of “done” is, the other two legs of empirical process control don’t work. When someone describes something as done, everyone must understand what done means.
But still not yet quite the now seemingly well established term “Definition of Done” that we see today.
