La Definition of Done (DoD) est l'une des idées les plus simples de Scrum — et l'une des plus mal appliquées. C'est la liste des critères qu'une user story doit satisfaire pour être considérée comme réellement terminée. Pas "le code est écrit". Terminée.
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.
La DoD transforme ce flou en un accord collectif et explicite, révisé à chaque rétrospective.
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
- Le PO a validé la story 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.
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.