Qu’est-ce que la definition of done ? Principes + avantages

Table des matières

Dans un contexte agile, on nous dit qu’il faut livrer vite et souvent afin de fournir un max de valeur au client et aux utilisateurs. Mais comment fait-on pour livrer vite et souvent sans rogner sur la qualité ?

Grâce à la definition of done. A ne pas confondre avec la definition of ready.

Je vous explique dans cet article ce qu’est la definition of done, ou définition de fini, pourquoi c’est une notion indispensable pour toute équipe agile, et comment le mettre en place.

Qu’est-ce que la definition of done ?

La definition of done est une liste contextuelle de critères à vérifier, permettant de s’assurer qu’un travail est réalisé à 100% et est prêt à être livré au client.

Elle fixe le niveau d’exigence de qualité minimum à respecter pour qu’une user story soit considéré comme terminée et que l’on puisse livrer l’incrément au client.

C’est en quelque sorte un contrat de fonctionnement entre l’équipe de développement et le reste du monde.

Dans un contexte agile, l’équipe ne s’engage pas sur une quantité de travail à effectuer (le nombre d’items intégrés au sprint backlog). Elle s’engage sur ce que signifie un travail de qualité via la definition of done.

L’équipe ne sait pas à l’avance ce que contiendra réellement un incrément, mais elle sait que celui-ci satisfera aux exigences de qualité. Si vous n’êtes pas familier avec la notion d’incrément, je vous invite vivement à consulter cet article, les deux notions étant intimement liées.

La definition of done permet ainsi de bien faire le travail du premier coup. L’équipe Scrum s’évite ainsi plus tard de corriger des bugs à foison et d’avoir de la dette technique. Avoir une bonne definition of done et la respecter, c’est faire preuve d’excellence opérationnelle.

Half done is not done. 99% done is not done.

Quality first.

La definition of done amène de la transparence

La definition of done, ou définition de fini, est considérée comme un engagement de l’incrément, qui est l’un des trois artefacts Scrum. 

On sait grâce à elle ce que veut dire terminer dans l’équipe et en dehors de l’équipe. Car oui, on n’a pas tous la même définition de fini.

Un travail terminé, pour vous, ça veut dire quoi ?

  • Un code écrit ?
  • Un code écrit et fonctionnel ?
  • Un code écrit et fonctionnel + la documentation associée ?
  • Un code testé et validé, revu par ses pairs, et prêt à passer en production ?

Il y a autant de définitions qu’il y a d’être humain. C’est pourquoi la DoD permet de clarifier tout cela.

Elle apporte donc de la transparence dans et en dehors de l’équipe, et permet de favoriser la confiance nécessaire pour bien collaborer.

Lors d’une sprint review, il est tout à fait possible de demander à voir les rapports de tests, la documentation, etc, associés à une fonctionnalité. Tout ce qui est dans la definition of done devient des livrables permettant d’attester de la qualité du travail fourni.

Là dans ce cas, on peut pas vraiment dire que le travail est terminé… La definition of done n’est pas respectée. Dommage !

Definition of done vs Critères d’acceptation : quelles différences ?

La definition of done n’est pas la même chose que les critères d’acceptation. Je m’explique :

  • Definition of done.
    Elle est commune à l’ensemble des éléments du backlog.
  • Critères d’acceptation.
    Ils sont unique et associés à un seul élément du backlog : la user story.
CaractéristiquesDefinition of DoneCritères d’acceptation
DescriptionIndique ce qui doit être fait pour qu’une user story soit terminée (tests, documentation, etc…)Indique les conditions de satisfaction métier d’une user story qui permettent de satisfaire l’utilisateur
UsageCommune à tous les éléments du backlog.Unique pour chaque user story.
Garant et ResponsabilitésL’équipe de développement est garante et responsable de la definition of done.Le Product Owner est garant des critères d’acceptation.
ÉvolutivitéPeut évoluer en rétrospective.Sont négociés au moment de la rédaction d’une user story.
QualitéLa definition of done garantit le respect des critères d’acceptation, en plus d’autres éléments.Le respect des critères d’acceptation ne garantit pas le respect de la definition of done.

Pour aller + loin : Découvrez dans cet article les principales différences entre la definition of done et la definition of ready.

Pourquoi il est impératif d’avoir une definition of done pour un projet agile ?

Sans definition of done, il serait quasiment impossible de fournir un haut niveau de qualité, et de livrer de la valeur régulièrement à votre client. 

Voici ce que vous permet une définition de fini :

  • Améliore la planification et de la prédictibilité.
    Au moment de la planification du sprint planning, on prend en compte tout ce qu’on doit faire dans le definition of done afin d’estimer le travail que l’on pourrait accomplir dans un sprint. Idem lors de l’estimation des story points associés à chaque user story. Ces points d’effort peuvent varier en fonction de la definition of done.
  • Réduit l’incertitude.
    En précisant ce qu’est un travail fini, on réduit l’incertitude lié au projet et aux futurs sprints.
  • Apporte de la transparence.
    Tout le monde dans l’équipe Scrum et dans les parties prenantes sait ce qu’est un travail terminé. La definition of done faclite la communication et apporte de la transparence, pilier essentiel qui amènera la confiance.
  • Assure un niveau de qualité minimum.
    Fini les fonctionnalités livrées et terminées à 99%. Avec la definition of done, un travail est fini ou ne l’est pas. Cela permet d’assurer des exigences de qualité sur les incréments livrés au client. Tant que l’incrément n’est pas fini à 100% il n’est pas terminé. On ne le montre donc pas en sprint review, et on ne comptabilise pas les points dans la vélocité de l’équipe. Pas de bras, pas de chocolat
  • Apporte les bonnes pratiques dans l’équipe.
    La definition of done permet d’apporter des bonnes pratiques au sein de l’équipe telles que le pair review pour le code informatique, les tests unitaires, les tests d’intégration, les recettes internes, etc…
  • Fait monter les juniors en compétence.
    Lorsque des juniors intègrent une équipe mature sur la definition of done, ils doivent nécessairement monter en compétences pour que leur travail soit considéré comme terminé.
  • S’adapte parfaitement au contexte du projet.
    La definition of done varie d’un projet à un autre. Elle évolue également dans le temps. Cela permet de s’adapter parfaitement au contexte évolutif et incertain du projet.
  • Limite la dette technique.
    En fixant des exigences minimum de qualité, on s’évite de nombreux bugs et on limite ainsi la dette technique du projet.

Qui rédige la definition of done ?

La definition of done, ou définition de fini, est décrite conjointement par les membres de l’équipe Scrum. Elle est donc acceptée de tous, et doit être respectée au quotidien par la suite.

Dans les méthodes agiles, la qualité n’est plus l’affaire d’une seule personne telle que le responsable qualité. La qualité, c’est l’affaire de tous. 

Avec Scrum, la qualité ainsi que la responsabilité de la definition of done est répartie entre tous les membres de l’équipe.

Chacun doit s’assurer que le travail fourni satisfait les exigences de qualité et satisfait en tout point les critères d’achèvement et les critères d’acceptation décrits dans la definition of done.

Petite précision cependant : le Product Owner peut être consulté par l’équipe (c’est même recommandé), mais il ne décide pas de la definition of done, c’est à l’équipe de développement de le faire.

Quand faut-il créer la definition of done ?

La definition of done doit être décidée avant le premier sprint, avant le sprint planning ou au plus tard au tout début du sprint planning.

En effet, cette notion permettant de savoir ce qu’est réellement un travail fini, il est indispensable de le définir AVANT de décider les items à intégrer au sprint backlog.

ça se comprend aisément, puisqu’en fonction de la définition de ce qu’est une user story terminée, on peut passer de 3 jours de travail à 3 semaines.

Ce serait totalement idiot et contre-productif d’estimer le travail que l’on peut réaliser dans un sprint sans savoir précisément ce que cela représente.

Exemples de definition of done

La definition of done prend généralement la forme d’une checklist listant ce qui doit être fait avant qu’un travail soit considéré comme terminé.

Voici quelques éléments qui peuvent apparaître dans une definition of done :

  • Le développement est terminé.
  • Les tests unitaires sont réalisés et sont OK.
  • Le code a été revu par un autre programmeur.
  • La qualité s’améliore.
  • La dette technique diminue.
  • Les maquettes graphiques sont respectées.
  • Les pages du site web se chargent en moins d’une seconde.
  • L’intégration continue fonctionne.
  • L’incrément est utilisable sur un environnement de test.
  • La documentation est écrite.
  • L’application de démo est disponible.
  • La recette de la fonctionnalité a été effectuée par l’équipe.
  • Les critères d’acceptation de la user story sont respectés.

La definition of done est-elle commune à toutes les tâches ?

Il n’existe qu’une seule definition of done au sein d’une équipe agile ou Scrum. Cette définition est commune à l’ensemble des user stories (les « tâches ») présentes dans le backlog.

Cependant, les critères d’acceptation des user stories peuvent varier en fonction du travail à réaliser.

C’est pour cela qu’on intègre généralement l’élément suivant dans une definition of done : « Les critères d’acceptation de la user story sont respectés »

Ces critères étant spécifiques à une user story, cela n’aurait aucun sens de l’intégrer à la définition de fini qui elle est générale.

Une definition of done peut-elle évoluer en cours de projet ?

La definition of done peut et doit évoluer durant le projet, grâce à la rétrospective, qui permet d’augmenter le niveau de qualité du travail fourni par l’équipe Scrum.

L’évolution se fait en fonction des besoins rencontrés : certains éléments peuvent être ajoutés à la DoD alors que d’autres peuvent être enlevés si cela n’a plus de sens de les garder.

La bonne pratique est de garder la definition of donne la plus petite possible et de laisser émerger les besoins. L’équipe Scrum voit ainsi l’intérêt de réaliser telle ou telle action supplémentaire dans la definition of done.

J’insiste sur ce point : chaque action doit avoir un sens. Si des éléments de la definition of done ne sont pas ou plus respectés, c’est que c’est le moment de la revoir.

Posez-vous la question suivante : « Quel est l’élément de la definition of done que l’on respecte le moins ? Et pourquoi ? A t-il encore une utilité ?

Ne changez jamais la definition of done au cours d’un sprint : cela anéantirait le travail réalisé jusque là. Le bon moment pour faire évoluer la définition de fini est la rétrospective.

Comment gérer la definition of done quand on a plusieurs équipes ?

Lorsque plusieurs équipes travaillent sur un même produit, il est primordial de partager la même définition de fini, sans quoi la qualité et la stabilité du produit ne peuvent pas être assurées au moment où les différentes fonctionnalités développées sont fusionnées.

Il faut donc créer une definition of done commune contenant un niveau d’exigence minimal. Libre ensuite à chaque équipe d’aller plus loin et d’être plus stricte.

Vous pouvez partir de la definition of done de l’organisation ou du produit si l’une d’entre elles exisxte déjà. Sinon, réunissez les membres des différentes équipes, ou leurs représentants, afin de déteminer ensemble ce que signifie un travail réalisé à 100%.

Faut-il inclure la mise en production dans la definition of done ?

La definition of done peut inclure la mise en production pour valider un incrément, mais ce n’est pas indispensable. Tout dépend de la stratégie de livraison adoptée. Cela se débat en équipe.

Si la stratégie définie avec le Product Owner est de livrer des releases de temps à autre, et pas les fonctionnalités dès qu’elles sont prêtes, alors inclure la mise en production dans la definition of done n’a aucun sens.

Cependant, l’équipe a dans ce cas tout intérêt à inclure les éléments préparant la mise en production dans la définition de fini. Elle peut par exemple déployer cette fonctionnalité sur un environnement de test afin d’éprouver les procédures d’installation.

De manière générale, votre definition of done doit s’approcher le plus possible de la mise en production, pour éviter les surprises.

En effet, si vous découvrez le jour J de la mise en prod que votre fonctionnalité ne s’intègre pas,c ‘est trop tard. Et ce n’est pas la définition d’un travail fini à 100%.

Souvenez-vous de ce que nous dit le Scrum Guide : « Un incrément est potentiellement livrable et doit être utilisable ».

Autrement dit, agissez comme si la mise en production aura lieu demain.

Comment rédiger une definition of done efficace ?

On l’a vu, rédiger une bonne definition of done est indispensable pour assurer un haut niveau de qualité dans le travail fourni et atteindre l’excellence opérationnelle.

Voici les meilleurs conseils d’experts pour définir une bonne définition de fini :

  • La definition of done n’est pas une bonne résolution. Ce qu’on écrit, on le fait.
  • Elle doit bouger et évoluer dans le temps, notamment en rétrospective.
  • Gardez la definition of done la plus petite possible. Laissez-la émerger en fonction des vrais besoins.

Pour découvrir la suite des conseils d’experts sur l’écriture d’une bonne définition de fini, je vous invite à consulter cet article.

Image de Thibault Baheux

Thibault Baheux

Tour à tour chef de projet puis manager d'équipe depuis 2008, je suis aujourd'hui directeur de projet indépendant. J'ai décidé via ce site de démocratiser la gestion de projets et de la rendre accessible à tous. Mes certifications : Prince2 Foundation, CompTIA Project+ certified, PSM1, PSPO1, Lean Six Sigma Black Belt.

Devenez un chef de projet performant

Et recevez dans votre boîte mail un exemplaire du guide « 15 facteurs-clés pour réussir vos projets ».

Ce guide est un condensé de conseils pratiques, tirés de mes 14 années d’expérience en pilotage de projets.