Definition of Done (DOD)… or when the “Go Live” sounds like fingers in the nose

An example of "Definition of Done" or DOD.

Bob: “Okay, this is it, i have finished developing this module. Deployment is done !”

Gerard: “Well, I can’t see nothing …?”

Bob: “On my workstation it works !”

Come on, admit it … you’ve already lived such a drama isn’t it ? :-)

One of the things I like in Scrum, and it my opinion it is one of its greatest strengths! I like that, when you said that a task or a User Story is done … well it is really done. In the case of an IT project, done means that stuff is developed, tested, documented, deployed on the test server etc. This is What Agile call the Definition of Done (DoD). The principle is simple: to switch a User Story in the column “Done” of the board, all the DOD criteria are met.

We sometimes use the term “Production Ready”, meaning that once your User Story completed and validated by the client, it can potentially be put into production. No further action is required.


Regarding the management of the documentation we try to apply some principles of “Lean”. I mean produce only documents with high added value. Often we can transform the question “do you have documentation?” in “what is you question ? What information are you looking for ?”. Then we provide the information. The idea is not to spend tens of days to produce documents quickly outdated. Warning! I’m not on trial with “doing documentation”. Documentation is useful but I think it is a means and not a goal to achieve. While i’m writing this paragraph I realize that this problem could be the subject of several articles.

Anyway the point is that i have a new crush about how we can do documentation… the use of video. Personally I use iShowU on the Mac that allows you to do video screenshots in a very simple way. I strongly believe in this: it is faster, more fun for the person who must “read” the document, easier to update.

The Go Live

The biggest slap that I receive using Scrum is how the production launch (i mean the go live) was …. cool! Yes you read it well. In fact, as we respect the DOD, as each month we did a demo to the client, the go live has been … just another sprint and no more. Since the deployment procedures were used for each sprint, the start of production was a simple roll on to another server.

Well now I will not lie to you … when the date of the go live comes close,  my pulse start to beats faster and faster and I expect problems and bad surprises. Our production launch has nevertheless taken a few hours and needed one or two minor manual adjustments. But honestly, in more than ten years of my career, I had never a go live o easy … and I must say that this was not to displease me.

Capitalizing on tests

Several points of the DOD concern testing, the advantage of writing tests is simple… When you are ready to deploy, you have a huge “set” of tests that can give you a good indicator of the quality of the release. In addition, for the next versions of your software, you can still use the “old” tests for the regression testing. By the way, i would like to thank the team with whom I worked. For the first time I did not have to “negotiate” the fact that we must write tests. They were all a lot “quality minded”. A member of the team had even developed a system requiring that all tests must be “green” to each commit … yes we are true psychopaths :-)

Le "DOD" en contexte
DOD in context, don't hesitate to update it on each "sprint review".

Finally, DOD is a living document and his lifetime is the time line of the project, in the example of DOD that you find at the bottom of this post, you will see that we added some things during the project (allocation of user rights and negative error handling). We consider that DOD is so much important that we placed it in the middle of Paul (So we call our “Scrum” Board). See picture.
I would like to thanks Bob and Gerard ;-)


More info:

Blog Post on Definition Of Done (en)

Example of Definition Of Done (ppt): Feel free to use it, just give me some credits.

This content is published under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.

Claude Aubry

Bonne publicité pour cette pratique essentielle pour la qualité. En tant que défenseur de la francophonie, je regrette l’utilisation du terme anglais, alors que la traduction n’est pas trop difficile. Je l’appelle Signification de fini (SDF! ).


Bonjour Claude et merci pour ton commentaire !

Je comprends ton commentaire et en toute sincérité je respecte les gens qui combattent pour que le français reste une langue “forte”. Même si dans ce cas le terme SDF peut être mal perçu :-)

Sinon ici en Belgique…un pays dont la complexité est inversément proportionnelle à sa taille ;-) Comme nous avons 3 langues nationales, il est parfois de bon ton d’utiliser l’anglais afin de ménager les susceptibilités.

Je me permets de faire la pub pour ton blog: à mes lecteurs n’hésitez pas à visiter !



Bonjour Bruno,

super! cet article est inspirant et du coup avec l’equipe on a reflechit à notre DOD (en se limitant au DODD, definition of development done ;) )
voici les retours:
1) tout les requirements liés sont couverts
– recomparer par rapport aux analyses (et oui on a des analyses…)
– revoir avec l’analyste functionel
2) le code est unit testé
– le unit testing fait partie de la responsabilité du dvp, à lui de décider si ils ont une valeurs ajoutés pour chaque methode…..
3) basic testing ok (objectif pas de defect blocking une fois en environnement de tests)
– revoir les tests basiques avec l’analyste avant de deployer
4) suivre la procedure clearcase pour le commit du code
– et oui on utilise ce fabuleux outil qu’est clearcase., la procedure est un bien grand mot pour decrire les etapes pour delivrer son code sans impacter les autres et c’est un autre sujet…
5) Doc technique, mise à jour….

voilà rapidement un autre retour d’experience en esperant qu’il est utlie… ;)


Merci pour ton retour Tom !

J’aime bien l’idée du DODD un bon compromis si tu ne peux pas aller plus loin.

J’aime bien aussi l’idée de responsabiliser le développeur sur les Unit Tests

J’ai déjà utilisé clearcase et je me demandais si ton “fabuleux” était ironique ou pas :-)

Merci pour le retour ! Et OUI ça aide !


Sebastien Arbogast

Personnellement j’ai aussi tendance à rajouter de l’analyse statique à ma DOD: des trucs comme Findbugs en Java, ou les outils d’analyse de certains IDE permettent de détecter certains bugs potentiels que les tests auront laissé passer (et oui les tests unitaires c’est comme les préservatifs: il suffit d’une fuite), tout en améliorant la qualité du code:

Un autre élément important ce sont aussi les code reviews et le refactoring (ouh la débauche d’anglicismes). J’ai vu des équipes agiles ou aucun code n’était committé avant d’avoir été revu par au moins une personne. Et souvent le code review mène à un refactoring. De manière générale, un développeur n’écrit jamais du bon code du premier coup, surtout quand il y a des tests unitaires, parce que son objectif est d’abord et avant tout de faire passer le test. Or le test ne contrôle pas la lisibilité, la maintenabilité ou la performance du code. C’est là que faire revoir son code par un autre membre de l’équipe aide beaucoup.

Your email address will not be published. Required fields are marked *