The definition of done is the set of criteria that we give ourselves to consider in agile that the elements we’re working on are done, or not. Done is essential, because it allows us to have something concrete. We move out of hypothesis, we have something that we can sell, give, propose, try, etc., we’re going to learn. Feedback is always interesting, even before “done”, but naturally with done it takes on much more value. And done allows us to go seek feedback elsewhere (end users, outside in the external world, etc.). Done is also binary, it’s done or it’s not done. This polarity is clear and allows a truly simplified reading of work in progress (that, we have it, that we don’t have), and opens toward more judicious trade-offs. With this strict notion of done (or not), we avoid the “we have 80% of this feature and 70% of that one” which, as you all know, doesn’t mean anything in real life. When people tell us “we have 80% of this feature” very often, they express the idea that 80% of the time allocated to implementing this feature has been consumed. But nothing indicates that the remaining 20% won’t take more than the preceding 80%. And so we want feedback regularly and we want done things regularly to learn, sell, give, try, etc., as soon as possible. And so we fall back into a need to express done things that make sense (on the functional, usage, business, commercial level) with fairly small elements (size, implementation effort). But that’s not the subject of this article but rather of this one.

I return to this definition of done which is a difficult element, perhaps the most difficult, in the agile sphere for teams, what form does it take, what does it contain, what must we be vigilant about? …in my opinion.

  • The definition of done will allow us to clarify our project status: that, we have it, that we don’t have.
  • The definition of done will allow us to deliver and learn
    before we don’t really know, when it’s done, I deliver and I learn.
  • The definition of done will allow us to harmonize our points of view and constraints on what “done” means.

Accessibility and intelligibility of the definition of done

Why is the definition of done in my eyes the most difficult element of an agile team?

  • Because it must be respected otherwise what’s the point of writing it.
  • Because it’s ultimately the level of quality that we give ourselves, so it’s essential.
  • Because it touches different levels: tasks? Yes. User stories? Yes. Features? Yes. Releases? Yes. Architecture? Yes. Design? Yes. Methods and processes? Yes. Documentation? Yes. Charter? Yes. etc.
  • Because it must make sense in an organization: if the definition of done isn’t somewhat linked to the environment it belongs to, what’s the point? More clearly and taking an IT project example: if your definition of done doesn’t take into account network bandwidth load when you integrate your done work into the common base this omission becomes heresy. The definition of done of a project, a product, a team must not ignore its ecosystem.
  • Because it must make sense for the team: useless to give a definition of done to a team that we know perfectly well won’t be able to respect it. Useless to ask a team through the definition of done to respect response times that it won’t be able to respect (for X reasons). You’re simply teaching it NOT to respect the definition of done. And therefore simply to respect nothing.
  • And the cherry on top that I care about a lot: the definition of done must be clear, shared, always in everyone’s head, for this I ask that it not exceed … 9 elements. In accordance with the magic number of 7 (-2/+2) which Princeton University has been telling us for 50 years is the number of objects that can fit in a human’s working memory. For everyone to be uncompromising and clear with the definition of done it must be constantly present in mind. No one is supposed to be ignorant of the definition of done. Personally I understand all these definitions: of ready, of done, of release, of production, etc., that I see flourishing. I understand. Intellectually they make sense. But in my view I prefer the rigor, the clarity induced by a short definition, reduced to the essential, to the intellectual completeness of all these diverse and varied definitions (I’m not even talking about quality plans with definitions of done spanning several pages, I take my hat off to those who respect them or even read them). Having the law in mind, the accessible and intelligible framework reinforces the autonomy and involvement of the team.

So my two rules that supersede the others, because they will build our behavior, our culture, in relation to this notion of done and quality:

  • No more than 9 elements, because no one can ignore its importance, its existence and its content, no one can ignore the level of requirement that we expect. And its accessibility, its compact aspect will facilitate our autonomy and our involvement toward it.
  • It must be achievable by the team. It’s unthinkable
    to teach the team to ignore or not respect the *definition
    of done*. If this isn’t possible: the team cannot
    respect the definition of done, the product cannot be viable
    without this definition of done, real reflection must take place
    team change? Product change?

What does it contain?

If I had to take a classic specification document and I had to adapt it to an agile context I would say: take all the functional, business elements, and place them in your backlog, in your expression of need, take all the other elements and place them in the definition of done. We’ll find technical elements there: you must use such and such component, or tool; we’ll find performance elements there: it must work with a million simultaneous users, have high availability, etc.; we’ll find method elements there: all completed tasks must be reviewed by another team member, validation is done on the integration platform, etc.

But this list is reduced to 7 (+2/-2) elements. It’s not SO complicated. Lots of choices are implicit and don’t need to be integrated into the definition of done. I estimate that you have two options: either not reduce the list, and have it not really be respected. Or you hurt yourself a bit and reduce it to 9 elements and that those at least not be forgotten.

Who decides what it contains?

Hmmm. Well… all the people concerned by what’s going to be produced. With arbitration by the business, the product owner, and agreement on feasibility by the team. Another complication therefore.

What form does it take?

A simple list displayed on the wall: no one is supposed to be ignorant of the definition of done. So 5 to 9 elements (I remind you that it’s my point of view and that it’s a minority view).

Here’s an example on an IT project (and it must be discussed aloud with the team and the product owner to clearly delimit what the words express):

  • must work on firefox, chrome and IE
  • must work with Elastic Search
  • must work with a million simultaneous users
  • all web pages must have online help
  • all tasks are reviewed by another team member
  • all validations take place on the preproduction platform
  • all developed elements have automated tests
  • nothing useless is present

You see nonetheless that things must be clarified (automated tests? etc.). But it’s clarified within the team. This list is displayed and must be respected for the elements (tasks ? Features? User stories? Release?) to be judged “done”.

Can it evolve?

At your own risk. If you say that it’s not a million simultaneous users, but ultimately ten, you understand that everything you’ve judged “done” previously is potentially called into question. If you add in the middle of the stream: the entire interface must be in English AND in Chinese, everything you’ve accomplished before is perhaps compromised. But it can evolve naturally.

Feedback

Nicolas

Completely agree the definition of done is an important element and many teams neglect it or don’t respect it. I would add that it’s an element of transparency and that each team member must be able to explain it to the different stakeholders. On the other hand, the definition of done sets the TONE for the team when defining how it’s going to go about creating the product or increment. Regarding the number of criteria, I agree with you, it’s not necessary to make a Prevert-style list, personally I always indicate not to exceed ten. After that what the list contains belongs only to the team, another team in the same organization could have a different definition, because each team works differently.