La Definition of Done (DoD) est l'une des idées les plus simples de Scrum : et l'une des plus mal appliquées. Le Scrum Guide la définit comme la description formelle de l'état de l'Increment lorsqu'il respecte les mesures de qualité requises pour le produit. Lorsqu'un élément du Product Backlog satisfait cette définition, un nouvel Increment est créé.
La Definition of Done donne à tous la même compréhension de ce qui appartient réellement à l'Increment. Les critères exacts dépendent du produit et des standards de l'organisation.
Le problème qu'elle résout
Sans Definition of Done explicite, chaque développeur a sa propre définition implicite du mot "terminé". Pour l'un, c'est quand le code compile. Pour l'autre, quand les tests passent. Pour un troisième, quand la PR est mergée. Résultat : lors de la sprint review, des stories "terminées" présentent des bugs, n'ont pas de tests, ou ne sont pas déployées en staging. C'est précisément lors de la sprint review que ces écarts deviennent visibles aux parties prenantes.
La DoD transforme ce flou en un accord collectif et explicite, révisé à chaque rétrospective : c'est une exigence explicite du Guide Scrum 2020.
Exemple de Definition of Done
Voici une DoD typique pour une équipe web :
- Le code est écrit et revu par au moins un autre développeur (PR validée)
- Les tests unitaires couvrent les nouveaux cas métier (couverture ≥ 80 %)
- Les tests d'intégration passent en CI
- La fonctionnalité est déployée en environnement de staging
- Les critères d'acceptation de la story sont vérifiés manuellement
- La documentation technique est mise à jour si nécessaire
- Aucune régression détectée sur les fonctionnalités adjacentes
- Si l’équipe l’a explicitement retenu : validation fonctionnelle sur staging
Definition of Done vs Critères d'acceptation
La confusion est fréquente. Voici la distinction :
- Les critères d'acceptation sont spécifiques à une story : ce que cette fonctionnalité précise doit faire.
- La Definition of Done est commune à toutes les stories : le niveau de qualité que l'équipe s'engage à respecter systématiquement.
Une story peut satisfaire ses critères d'acceptation ("le bouton fonctionne") sans satisfaire la DoD ("les tests ne sont pas écrits"). Dans ce cas, elle n'est pas terminée : quelle que soit la pression du PO.
Definition of Ready vs Definition of Done
La DoD a un pendant moins connu : la Definition of Ready (DoR). Là où la DoD définit ce que "terminé" signifie en sortie de sprint, la DoR définit ce que "prêt à démarrer" signifie en entrée. Une équipe peut convenir de critères de préparation pour guider la sélection au sprint planning, mais cette DoR n'est pas une exigence du Scrum Guide.
DoR typique :
- Story rédigée au format standard (En tant que / Je veux / Afin de)
- Critères d'acceptation écrits et clairs
- Estimée par l'équipe en story points
- Dépendances identifiées et non bloquantes
Sans DoR, les stories arrivent au sprint planning incomplètes. Sans DoD, elles en sortent avec de la dette cachée. Les deux ensemble créent un cycle de qualité reproductible.
Comment construire sa DoD en équipe : 4 étapes
Étape 1 : Session de kickoff avec l'équipe entière
Réunissez développeurs, Scrum Master et PO. La question de départ : "Qu'est-ce qui doit être vrai pour que cette story soit livrable sans honte à un client ?" Chaque réponse est un critère candidat. Listez tout sans filtre dans un premier temps.
Étape 2 : Trier le réaliste de l'aspirationnel
Passez la liste au vote : "Pouvons-nous tenir ce critère sur chaque story, chaque sprint, même sous pression ?" Un critère que vous ne pourrez tenir que 60 % du temps n'appartient pas à la DoD : il appartient à une liste d'objectifs d'amélioration. La DoD doit être un engagement tenu à 100 %.
Étape 3 : Publier et rendre visible
Affichez la DoD dans votre outil de gestion de projet, épinglez-la dans votre canal d'équipe, imprimez-la si vous travaillez dans le même bureau. Une DoD que personne ne lit est une DoD qui n'existe pas.
Étape 4 : Réviser à chaque rétrospective
La DoD est un document vivant. À chaque rétro, posez deux questions : "Avons-nous respecté la DoD sur ce sprint ?" et "Y a-t-il un critère à ajouter ou à reformuler ?" Une DoD qui ne change jamais en 6 mois d'équipe est suspecte.
La DoD évolue avec l'équipe
Au premier sprint d'une nouvelle équipe, une DoD de 3 critères est réaliste. Après 6 mois de pratique, 10 critères est raisonnable. La rétrospective est le bon moment pour faire évoluer la DoD : soit en ajoutant des critères ("on veut aussi un test de charge"), soit en constatant qu'un critère n'est jamais respecté et en comprenant pourquoi.
Une DoD qui ne change jamais est une DoD que personne ne lit vraiment.
Les erreurs à éviter
La DoD aspirationnelle
"100 % de couverture de tests", "zéro dette technique", "documentation complète pour chaque fonction". C'est une liste de souhaits, pas un engagement réaliste. Une DoD inatteignable sera ignorée dès le premier sprint sous pression.
La DoD secrète du PO
Certains PO considèrent qu'une story est terminée quand eux en sont satisfaits : indépendamment des critères techniques. Résultat : l'équipe de développement ne sait jamais quand une story est vraiment close. La DoD doit être co-construite et partagée.
Baisser la barre sous la pression
"Cette fois c'est urgent, on skip les tests." Ce genre de décision prise en sprint génère une dette technique qui ralentira les sprints suivants. La DoD est précisément là pour résister à cette pression. Si elle est régulièrement contournée, c'est un signal que le sprint est surchargé.
Afficher la DoD physiquement
Les équipes les plus disciplinées affichent leur DoD sur un mur (ou en épingle dans leur outil) et la consultent avant de déplacer une carte en "Terminé". Ce geste anodin crée une habitude de rigueur qui paie sur le long terme.
Definition of Done dans Manifst
La Definition of Done est configurée dans les paramètres du projet, en français et en anglais. Lors du sprint planning, elle est copiée dans le sprint afin que l'équipe puisse la relire ou l'adapter sans modifier rétroactivement les sprints précédents.
Elle apparaît ensuite dans le récapitulatif du planning. Chaque ticket possède en parallèle ses propres critères d'acceptation. La DoD n'est pas actuellement affichée dans le kanban : l'équipe doit la consulter depuis le sprint ou les paramètres du projet.
Découvrir la gestion de la qualité et des sprints dans Manifst.
Essayez Manifst gratuitement et définissez votre DoD dès le premier sprint.