Definition de Done : exemple, checklist et atelier dans Scrum

L’autre jour, j’ai préparé un atelier avec une collègue. Nous nous sommes rapidement mis d’accord sur le contenu, il ne nous manquait plus que la présentation PowerPoint adéquate. Pour pouvoir travailler le plus efficacement possible sur la présentation, nous l’avons divisée en plusieurs thèmes. Lorsque nous nous sommes réunis pour discuter du projet final, un problème majeur est apparu : nous avions des idées très différentes sur ce qui caractérise un “projet final”. 

Ce problème peut également survenir dans les équipes Scrum agiles. Après deux semaines, l’équipe arrive à la fin du sprint, mais il y a un désaccord sur le fait de savoir si l’incrément de produit est déjà terminé et peut être déplacé de “en cours” à “terminé”. Ce désaccord entraîne des discussions qui, à leur tour, ont un impact négatif sur le climat de l’équipe. Pour éviter ces discussions et protéger la collaboration efficace au sein de l’équipe, il existe dans le monde Scrum un artefact appelé “Definition of Done” (DoD). 

Qu’est-ce que la Definition of Done dans Scrum ?

La Definition of Done est l’accord qualité commun d’une équipe Scrum. Elle décrit quelles conditions doivent être remplies pour qu’un incrément soit considéré comme terminé et utilisable. Ce n’est pas une liste personnelle de tâches ni une validation supplémentaire par un seul rôle, mais une norme transparente pour toute l’équipe.

Littéralement, Definition of Done signifie “définition de ce qui est terminé”. Il s’agit donc d’un accord de l’équipe sur ce qui doit être fait pour qu’une fonctionnalité soit considérée comme terminée. En pratique, la définition de l’achèvement peut être représentée comme une sorte de liste de contrôle qui permet de vérifier, pendant le sprint et surtout à la fin, si certains critères d’achèvement ont été respectés. Ces critères peuvent être les suivants pour l’équipe de développement logiciel : 

Exemple de Definition of Done : checklist pour les équipes Scrum

Une Definition of Done applicable en pratique peut, par exemple, contenir les critères suivants pour un produit logiciel :

• Les critères d’acceptation et les exigences métier sont remplis.
• Une documentation a été créée.
• Le code est entièrement implémenté et commenté.
• Une revue de code a été effectuée.
• Les tests automatisés s’exécutent avec succès ; les défauts pertinents et les risques de sécurité sont traités.
• La modification est intégrée et peut être vérifiée dans un environnement proche de la production.
• Le monitoring, le logging et, le cas échéant, les notes de version sont pris en compte.
• L’incrément est utilisable et répond au standard de qualité du produit.
• …

Cette liste est un exemple, pas un modèle universel. Une bonne DoD protège la qualité, reste applicable par l’équipe à chaque sprint et est adaptée lorsque le produit, les risques ou les contraintes techniques évoluent.

La Definition of Done n’est pas la même chose que l’impact produit

Une Definition of Done répond à une question importante : l’incrément respecte-t-il le standard de qualité convenu et est-il utilisable ? Elle ne répond pas automatiquement à la question de savoir si la modification produit l’effet souhaité sur le marché ou chez le client.

Pour la pratique, il est donc utile de distinguer trois niveaux :

• Done : L’incrément respecte la Definition of Done et peut être utilisé.
• Done-Done : La modification est intégrée, livrée et observable en exploitation.
• Impact produit : Le retour réel des clients montre si la modification résout un problème pertinent et augmente la valeur du produit.

John Cutler décrit donc le logiciel comme un système de services en évolution continue : les fonctionnalités ne sont pas des bâtiments définitifs, mais des moyens temporaires de créer de la valeur pour le client. Lis son point de vue dans The Work Is Never Done.

Gil Zilberfeld distingue en outre plusieurs significations de « Done » – par exemple lorsque le développement, les tests, la livraison ou les retours clients marquent chacun un degré d’achèvement différent. Tu trouveras son classement dans The Definition of Done, Done-Done and Really Done.

Important : « impact produit » ne devrait pas être formulé simplement comme un critère DoD supplémentaire. Une équipe Scrum doit livrer un incrément utilisable ; savoir s’il produit l’effet souhaité devient visible ensuite à travers le Sprint Review, l’utilisation et d’autres boucles d’apprentissage. C’est précisément cette distinction qui empêche la Definition of Done de devenir une liste de contrôle irréalisable.

Comment la Definition of Done s’articule avec d’autres pratiques Scrum efficaces, nous le montrons dans notre article Meilleures pratiques Scrum 2026.

Pourquoi une Definition of Done est-elle importante ?

Le fait que la fixation d’objectifs soit d’une énorme importance pour la performance n’est pas une nouvelle découverte. La fixation d’objectifs est un sujet très étudié en psychologie (cf. Locke & Latham, 2006). Il s’est avéré que la performance est la plus élevée lorsque les objectifs sont formulés de manière aussi spécifique que possible et qu’ils sont stimulants sans pour autant paraître inaccessibles. La définition de ce qui est fait n’est pas une méthode de fixation d’objectifs (si toutefois tu en as besoin). Aide à la définition d’objectifs Il s’agit plutôt de critères qui doivent être remplis pour atteindre l’objectif. 

Ces critères sont importants pour créer une compréhension commune au sein de l’équipe. Une compréhension de ce que chaque membre de l’équipe doit faire pour atteindre l’objectif commun. Il s’agit donc de performances individuelles qui, au final, s’assemblent pour former une performance d’équipe.

Si l’on considère la thématique du DoD du point de vue du Product Owner, les problèmes sont tout autres. Si le moment où l’on considère qu’un produit est terminé n’est pas clairement défini, il peut y avoir des désaccords avec le client lorsque le produit lui est présenté. Si cela se produit et qu’un produit non terminé est présenté, la possibilité de feedback de la part du client est bloquée. 

Amélioration continue

Étant donné qu’une définition du travail accompli n’est pas un concept statique, et qu’elle peut et doit être développée ou modifiée en permanence, elle offre également à l’équipe la possibilité d’apprendre. Si à la fin d’un sprint, l’équipe se rend compte qu’elle n’a pas pu répondre aux critères de la Definition of Done, les membres de l’équipe peuvent soit ajuster la Definition of Done pour correspondre aux performances réelles, soit l’équipe tire des conclusions pour le prochain sprint et modifie sa propre façon de travailler.

Essaie gratuitement Echometer maintenant & obtiens de nouvelles inspirations pour tes rétrospectives !

Essayer Echometer gratuitement

Ces réflexions concernant la Definition of Done devraient être menées par l’équipe dans le cadre de la rétrospective. possibles Echometer ItemsLes questions à poser pour se préparer sont les suivantes 

Nous avons des Definitions of Done claires pour nos exigences.

Je sais généralement où nous en sommes dans la réalisation de nos objectifs communs.

Mes objectifs sont alignés avec ceux de mes collègues.

Dans l’équipe, toutes les compétences dont nous avons besoin pour atteindre notre objectif sont couvertes.

Ils ne se demandent pas seulement s’il existe une définition du fait accompli au sein de l’équipe, mais aussi quelle est la transparence, l’autonomie et la clarté des rôles au sein de l’équipe.

Tu trouveras l’intégralité de l’outil Itempool dans notre Outil rétro.

Comment notre équipe peut-elle définir le Done ? Un exemple d’atelier

Nous t’avons montré ce qu’est une Definition of Done et pourquoi elle est importante pour une collaboration efficace dans les équipes Scrum. Cependant, si ton équipe n’a pas encore créé de DoD, tu te demandes certainement comment cela fonctionne. 

En principe, il est important que l’équipe prenne son temps lors de la création. A la fin, il devrait en résulter un document auquel chaque membre de l’équipe peut s’identifier et qui n’est pas seulement considéré comme un mal nécessaire. C’est pourquoi nous recommandons un format d’atelier avec le Scrum Master comme modérateur. Chaque membre de l’équipe doit réfléchir aux critères importants pour l’achèvement du produit et l’équipe peut ensuite résumer ces pensées. De la même manière, nous avons développé un format d’atelier pour les objectifs. Jetez un coup d’œilPour trouver des idées pour ton atelier de définition de l’argile ! 

Le DoD terminé peut être utilisé dans les rétrospectives, par exemple sous la forme de feux de signalisation de définition du travail accompli :  

1. Note tes critères de définition du fait accompli entre eux.
2. Dessine à côté de chacun d’eux une case rouge, une jaune et une verte.
3. Pour chaque point de la Definition of Done, chaque membre de l’équipe marque s’il a été bien réalisé, moyennement bien ou mal réalisé lors du dernier sprint. 
4. Discute des trois qui sont le plus souvent cités dans la zone rouge.
5. Ajuste ta définition de ce qui est fait, si nécessaire.

Conclusion - Terminé ?

Quelques mots pour finir : dans l’environnement agile, “fini” n’existe pas. Done signifie simplement que quelque chose est provisoirement terminé, mais que d’autres ajustements et améliorations peuvent et doivent suivre à tout moment. C’est l’un des nombreux aspects positifs du travail agile : l’amélioration continue. 

Ce qui est particulièrement intéressant, c’est que parfois, les points sont prêts jusqu’à ce que le client se manifeste et remette en question toute la solution, ébranlant ainsi les fondements des hypothèses sur les besoins du client. C’est dans ce genre de situation que l’on voit si l’équipe a vraiment donné la priorité aux avantages pour le client plutôt qu’à l’avancement du système de tickets.

Une définition claire de ce qui est fait peut éviter les conflits et augmenter ta performance. Si tu es intéressé par d’autres moyens d’atteindre cet objectif, tu devrais aussi consulter notre article à l’étonnante vérité derrière l’état d’esprit agile regarder. Ou enrichir tes rétrospectives en prenant en compte les dernières découvertes scientifiques en matière de psychologie.

C’est exactement avec cette promesse que nous avons développé notre outil rétro Echometer. Si tu veux savoir comment (et si) Echometer fonctionne, tu peux lire l’expérience de Holger avec notre outil :

Tu veux faire passer ton équipe à un nouveau niveau de performance ? Notre outil Retro t’aidera à le faire. Voici l’expérience de Holger :

Témoignage de Holger sur le Remote Retro Tool

Questions fréquentes sur la Definition of Done

Que doit contenir une Definition of Done ?

Une Definition of Done doit contenir tous les critères de qualité qu’un incrément doit remplir pour être utilisable. Des exemples typiques sont : critères d’acceptation remplis, revue de code, tests, contrôle de sécurité, documentation et possibilité technique de livraison. Les points applicables sont décidés par l’équipe pour son contexte produit.

Qui crée la Definition of Done dans Scrum ?

L’équipe Scrum développe et entretient la Definition of Done ensemble. Elle ne devrait pas être imposée par un seul rôle sous forme de liste de contrôle. Les organisations peuvent fixer des standards minimaux, mais l’équipe doit les comprendre et pouvoir les appliquer au quotidien.

Quelle est la différence entre Definition of Done et Definition of Ready ?

La Definition of Done décrit quand un incrément est terminé et utilisable. En revanche, une Definition of Ready peut contenir des critères de préparation d’un élément de travail, mais ce n’est pas un artefact officiel de Scrum et ne doit pas servir à déplacer la responsabilité ou les boucles de feedback.

Exemple pratique : notre Definition of Done interne chez Echometer

Une Definition of Done ne doit pas s’arrêter au code et aux tests. Chez Echometer, nous utilisons en interne une norme plus globale qui prend en compte, en plus de la fonctionnalité, l’UX, la maintenabilité, l’observabilité et la préparation de la mise en production. L’exemple suivant montre comment une équipe peut rendre ses propres critères de qualité concrets et vérifiables :

Domaine	Critères exemplaires
Fonctionnalité	La fonctionnalité spécifiée fonctionne, les cas limites typiques sont vérifiés, il n’existe pas de bugs connus, les fonctionnalités inachevées sont protégées par un Feature Flag et les données d’utilisation pertinentes sont collectées.
UX	Les états vides, les états de chargement, les autorisations, la gestion des erreurs, la localisation et l’affichage responsive sont pris en compte.
Maintenabilité	Les Coding Guidelines et les conventions pertinentes sont respectés, le code inutile et la dette technique volontairement laissée de côté ont été évités, et les informations importantes pour le monitoring et le débogage sont disponibles.
Déploiement	La modification est déployée en production ou préparée de manière ciblée via un Feature Flag, les Release Notes sont complétées et les parties prenantes concernées sont informées si nécessaire.

Cet exemple n’est bien sûr pas un modèle universel. Vous pouvez toutefois vous en servir comme base, l’enrichir avec vos propres définitions, le vérifier régulièrement et le faire évoluer comme un document vivant.

Sources

Locke, E. A., & Latham, G. P. (2006). New Directions in Goal-Setting Theory. Current Directions in Psychological Science, 15(5), 265–268. https://doi.org/10.1111/j.1467-8721.2006.00449.x