Qu'est-ce que la Definition of Done en Scrum ?

La Definition of Done (DoD) est un concept central de Scrum qui répond à une question apparemment simple : quand un travail est-il vraiment terminé ? Derrière cette simplicité se cache un outil puissant qui influence la qualité, la transparence et la prévisibilité de toute équipe Scrum.

Définition officielle

Le Scrum Guide 2020 définit la Definition of Done comme une description formelle de l'état de l'Increment lorsqu'il satisfait les mesures de qualité requises pour le produit. Quand un élément du Product Backlog satisfait la Definition of Done, un Increment est créé.

En termes plus concrets, la DoD est une checklist de critères de qualité que chaque élément du Product Backlog doit respecter pour être considéré comme terminé. Si un élément ne satisfait pas tous les critères de la DoD, il ne peut pas être présenté en Sprint Review et ne fait pas partie de l'Increment.

Pourquoi la Definition of Done est essentielle

Créer une compréhension partagée

Sans DoD, chaque membre de l'équipe a sa propre interprétation de ce que "terminé" signifie. Pour un développeur, c'est peut-être "le code est écrit". Pour un testeur, "les tests passent". Pour le Product Owner, "la fonctionnalité est en production". La DoD élimine cette ambiguïté en établissant un standard commun.

Garantir la qualité

La DoD est le garde-fou de la qualité. Elle empêche l'équipe de livrer du travail incomplet ou de qualité insuffisante sous la pression des délais. Chaque Increment qui satisfait la DoD atteint un niveau de qualité constant et prévisible.

Assurer la transparence

La DoD rend transparent ce qui est inclus dans chaque Increment. Les parties prenantes savent exactement ce que "terminé" signifie et peuvent avoir confiance dans ce qui leur est présenté en Sprint Review.

Faciliter la prévision

Une DoD stable permet à l'équipe d'estimer plus précisément le travail nécessaire pour terminer un élément du Product Backlog. Si la DoD change constamment, les estimations perdent toute fiabilité.

Qui définit la Definition of Done ?

C'est un point qui fait souvent débat. Selon le Scrum Guide 2020 :

• Si l'organisation a déjà une Definition of Done standardisée, toutes les équipes Scrum doivent la respecter comme un minimum.
• Si l'organisation n'en a pas, l'équipe Scrum doit en créer une adaptée au produit.
• Les Developers doivent se conformer à la DoD. Si plusieurs équipes travaillent sur le même produit, elles doivent partager la même DoD.

Le point important : la DoD n'est pas négociable au cas par cas. On ne décide pas qu'un élément est "fait sans tests parce qu'on manque de temps". La DoD s'applique uniformément à tous les éléments, Sprint après Sprint.

Exemples de critères pour une Definition of Done

Voici des critères couramment inclus dans une Definition of Done, organisés par catégorie :

Code

• Le code est écrit et respecte les conventions de codage de l'équipe.
• Le code a été revu par au moins un autre Developer (code review).
• Le code est versionné et mergé dans la branche principale.
• Aucune dette technique connue n'a été introduite sans décision explicite.

Tests

• Les tests unitaires sont écrits et passent avec un taux de couverture minimum défini.
• Les tests d'intégration sont écrits et passent.
• Les tests de régression passent.
• Les tests d'acceptation validés par le Product Owner passent.

Documentation

• La documentation technique est mise à jour.
• La documentation utilisateur est mise à jour si nécessaire.
• Les notes de release sont rédigées.

Déploiement

• L'élément est déployé dans un environnement de staging.
• Les critères de performance sont vérifiés.
• La sécurité a été vérifiée (scan de vulnérabilités, revue des permissions).

Qualité

• Aucun bug critique ou bloquant n'est ouvert.
• L'accessibilité a été vérifiée.
• La compatibilité navigateurs/devices a été testée.

Cette liste n'est pas universelle. Chaque équipe adapte sa DoD à son contexte, son produit et sa maturité.

Definition of Done vs Critères d'acceptation

La confusion entre la DoD et les critères d'acceptation est fréquente. Pourtant, ces deux concepts sont très différents :

Aspect	Definition of Done	Critères d'acceptation
Portée	Tous les éléments du Product Backlog	Un élément spécifique
Qui définit	L'équipe Scrum / l'organisation	Le Product Owner
Nature	Standard de qualité	Exigences fonctionnelles
Variabilité	Stable d'un Sprint à l'autre	Différente pour chaque élément
Exemple	"Le code a été revu"	"L'utilisateur peut filtrer par date"

Un élément est terminé quand il satisfait à la fois ses critères d'acceptation (exigences fonctionnelles spécifiques) et la Definition of Done (standards de qualité universels).

Comment faire évoluer la Definition of Done

La DoD n'est pas gravée dans le marbre. Elle doit évoluer avec la maturité de l'équipe et les exigences du produit.

Renforcer progressivement

Une équipe qui débute avec Scrum peut commencer avec une DoD minimale, puis la renforcer Sprint après Sprint. Par exemple :

• Sprint 1-3 : code revu, tests unitaires, déployé en staging.
• Sprint 4-6 : ajout des tests d'intégration et de la documentation.
• Sprint 7+ : ajout des tests de performance et de sécurité.

Utiliser la Retrospective

La Sprint Retrospective est le moment idéal pour discuter de la DoD. L'équipe peut décider d'ajouter ou de modifier des critères en fonction de son expérience et des problèmes rencontrés. Pour en savoir plus sur les erreurs fréquentes en Scrum, consultez notre article sur les anti-patterns Scrum.

Ne jamais réduire la DoD

Renforcer la DoD est une marque de maturité. La réduire est un signal d'alarme. Si l'équipe n'arrive pas à respecter sa DoD, le problème ne vient pas de la DoD : il vient de la quantité de travail sélectionnée ou des compétences de l'équipe.

Les erreurs classiques avec la Definition of Done

DoD inexistante

Certaines équipes travaillent sans DoD, ce qui revient à laisser chaque individu décider quand un travail est terminé. Le résultat : des Increments de qualité variable et une accumulation de travail non terminé.

DoD trop vague

"Le code fonctionne" n'est pas une DoD. Les critères doivent être suffisamment précis pour être vérifiables objectivement. Chaque critère doit pouvoir être évalué par un oui ou un non.

DoD différente selon les éléments

La DoD s'applique à tous les éléments du Sprint Backlog sans exception. Créer des exceptions ("cet élément est terminé même sans tests parce que c'est urgent") détruit la confiance dans l'Increment.

DoD négociée à la baisse en fin de Sprint

Sous la pression de livrer, certaines équipes allègent la DoD en fin de Sprint pour pouvoir marquer des éléments comme terminés. C'est une forme de dette technique déguisée qui reviendra tôt ou tard.

Confondre DoD et critères d'acceptation

Comme expliqué plus haut, ce sont deux concepts distincts. Les critères d'acceptation sont spécifiques à chaque élément. La DoD est universelle.

Definition of Done et dette technique

La DoD est directement liée à la gestion de la dette technique. Une DoD rigoureuse prévient l'accumulation de dette technique en s'assurant que chaque Increment respecte des standards de qualité élevés. A l'inverse, une DoD faible ou inexistante laisse la dette technique s'accumuler silencieusement, jusqu'à ce qu'elle devienne ingérable.

Le Scrum Master joue un rôle clé en aidant l'équipe à comprendre l'importance d'une DoD solide et en résistant aux pressions qui visent à l'affaiblir.

Definition of Done et certification

La Definition of Done est un sujet fréquent dans les certifications PSM I et PSM II. Les questions portent sur qui crée la DoD, ce qui se passe quand un élément ne la satisfait pas, et comment elle interagit avec les autres artefacts Scrum.

Points clés pour l'examen :

• Un élément qui ne satisfait pas la DoD ne peut pas être présenté en Sprint Review.
• La DoD est l'engagement associé à l'artefact Increment.
• Si l'organisation a une DoD standard, les équipes doivent la respecter comme minimum.
• Les Developers peuvent ajouter des critères à la DoD organisationnelle, mais pas en retirer.

Pour vous entraîner sur ces questions et bien d'autres, créez votre compte sur Outsmart et accédez à des parcours de révision adaptés à votre niveau.

En résumé

La Definition of Done est le contrat de qualité de l'équipe Scrum avec elle-même et ses parties prenantes. Elle définit ce que "terminé" signifie réellement et garantit que chaque Increment atteint un standard de qualité constant. Sans DoD, il n'y a pas de transparence, pas de prévisibilité et pas de confiance. C'est un outil simple mais fondamental que chaque équipe Scrum doit définir, respecter et faire évoluer.