logo
Rétrospectives
Poker de planification
Standups
Brise-Glaces
Tarification
Tableau de bord

La checklist definition of done dont votre equipe a vraiment besoin

Equipe agile debout autour d'un tableau blanc avec une checklist terminee, se tapant dans les mains apres avoir termine un increment de sprintEquipe agile debout autour d'un tableau blanc avec une checklist terminee, se tapant dans les mains apres avoir termine un increment de sprint Chaque equipe Scrum connait ce moment ou quelqu'un marque une story comme "terminee" et quelqu'un d'autre demande : "mais tu as ecrit les tests ?" Cet ecart entre ce qu'une personne considere comme fini et ce dont l'equipe a reellement besoin est exactement ce que resout une Definition of Done. Le Scrum Guide 2020 a eleve la DoD du statut d'element facultatif a celui d'engagement formel lie a l'Increment. Pourtant, l'etude de Ron Lichty sur la performance des equipes produit montre que seulement 45 % des equipes ont une DoD creee par leur propre equipe. Les autres travaillent soit sans DoD, soit suivent une checklist que quelqu'un d'autre leur a fournie. Le point interessant : seules les definitions of done creees par l'equipe sont correlees a une haute performance. Celles imposees de l'exterieur ne montrent aucune correlation.

Ce qu'est reellement la definition of done

La DoD est un standard de qualite partage qui s'applique a chaque element de travail que votre equipe livre. Ce n'est pas la meme chose que les criteres d'acceptation.
Definition of DoneCriteres d'acceptation
PerimetreUniversel, s'applique a tout le travailSpecifique a une story
ObjectifStandards de qualite et de processusExigences fonctionnelles
Qui la redigeToute l'equipe ScrumLe Product Owner (avec l'avis de l'equipe)
Exemple"Code revu par au moins un developpeur""L'utilisateur peut filtrer par plage de dates"
Les deux doivent etre satisfaits avant qu'une story soit terminee. Les criteres d'acceptation vous disent quoi construire. La DoD vous dit a quel niveau de qualite cela doit etre construit.

Une checklist definition of done a trois niveaux

Toutes les equipes n'ont pas besoin de la meme DoD. Une startup qui livre son MVP a des besoins en qualite differents d'une plateforme de sante avec des exigences de conformite. Voici une approche par niveaux.

DoD debutant

Pour les equipes qui debutent avec une definition of done formelle :

Code revu par au moins un autre developpeur

Tests unitaires ecrits et passants

Aucun nouveau warning ou erreur de compilation

Criteres d'acceptation verifies

Code fusionne dans la branche principale

Build reussi depuis le controle de version

DoD intermediaire

Pour les equipes avec un CI/CD etabli et quelques sprints d'experience :

Code revu par au moins un autre developpeur

Tests unitaires ecrits et passants

La couverture de code ne descend pas en dessous du seuil actuel

Tests d'integration passants

Aucun bug critique ou de haute severite restant

Criteres d'acceptation verifies de bout en bout

Deploye en environnement de staging

Le Product Owner a examine et approuve

Documentation technique mise a jour

Standards d'accessibilite respectes

DoD avance

Pour les equipes matures qui livrent en production a chaque sprint :

Code revu par au moins un autre developpeur

Tests unitaires, d'integration et de regression passants

Couverture de code maintenue ou amelioree

Analyse de vulnerabilites de securite reussie

Benchmarks de performance atteints

Deploye en production derriere un feature flag

Monitoring et alerting configures

Documentation utilisateur mise a jour

Notes de version redigees

Criteres d'acceptation verifies en production

Validation du Product Owner terminee

Equipe regardant un grand ecran affichant un pipeline CI/CD avec des coches vertes a chaque etape, representant des portes de qualite automatiseesEquipe regardant un grand ecran affichant un pipeline CI/CD avec des coches vertes a chaque etape, representant des portes de qualite automatisees Le bon niveau depend de votre contexte. Commencez par une checklist que votre equipe peut respecter de maniere constante, puis relevez la barre au fil du temps. Ajouter des elements que votre equipe saute regulierement ne fait qu'entrainer tout le monde a ignorer la DoD.

Pourquoi la DoD compte plus que vous ne le pensez pour l'estimation

C'est la que la plupart des articles sur la definition of done s'arretent. Mais le lien entre la DoD et la precision des estimations est la raison la plus sous-estimee de bien la definir. Le Scrum Guide le dit clairement : les developpeurs estiment avec plus de confiance lorsqu'ils comprennent leur Definition of Done. Quand votre equipe estime une story pendant le planning poker, cette estimation devrait inclure tout ce qui est necessaire pour satisfaire la DoD. Pas seulement ecrire le code, mais aussi la revue, les tests, le deploiement, tout. Les equipes qui n'estiment que l'effort de codage et decouvrent les activites liees a la DoD en fin de sprint s'engagent systematiquement sur trop de travail. Le travail n'a pas pris plus longtemps que prevu. L'estimation ignorait simplement la moitie du travail. Quand vous ajoutez de nouveaux elements a votre DoD (comme l'analyse de securite ou les tests de performance), attendez-vous a une baisse temporaire de la velocite. C'est sain. Votre velocite devient simplement honnete.

Cinq anti-patterns qui minent votre DoD

1. Definir et oublier

L'equipe a ecrit une DoD il y a six mois et ne l'a pas regardee depuis. Les outils changent et le produit evolue. Revisez la DoD lors de vos retrospectives meme si vous ne la modifiez pas a chaque fois.

2. Creee par une seule personne

Un tech lead ou un Scrum Master redige la DoD seul et la presente comme definitive. Le reste de l'equipe ne se l'approprie jamais, et la traite donc comme optionnelle. La solution : construisez-la ensemble lors d'un atelier. Toute personne qui fait le travail devrait avoir son mot a dire sur ce que signifie "termine".

3. Trop vague pour etre verifiable

"Le code est de bonne qualite" et "tests effectues" ne sont pas verifiables. Chaque element doit avoir une condition claire de reussite/echec. "Le code passe l'analyse statique avec zero probleme critique" est quelque chose que l'on peut verifier. "Le code est propre" est une question d'opinion. Personne regardant une checklist geante avec certains elements clairement marques comme termines et d'autres ambigus, illustrant la difference entre des criteres vagues et specifiquesPersonne regardant une checklist geante avec certains elements clairement marques comme termines et d'autres ambigus, illustrant la difference entre des criteres vagues et specifiques

4. Baisser la barre sous la pression

Quand les delais se resserrent, les equipes affaiblissent parfois la DoD pour livrer plus vite. Le Scrum Guide 2020 est explicite ici : la DoD peut evoluer pour ameliorer la qualite, mais elle ne doit pas etre affaiblie. Rogner sur la qualite ne vous accelere pas. Cela cree l'illusion de la vitesse tout en accumulant des problemes pour les sprints futurs.

5. Confondre DoD et criteres d'acceptation

La DoD est universelle. Les criteres d'acceptation sont specifiques a une story. Les melanger signifie que vous perdez soit le standard de qualite, soit les exigences fonctionnelles. Gardez-les comme des checklists separees qui fonctionnent ensemble.

Comment construire votre premiere DoD

Si votre equipe n'a pas encore de definition of done, voici une methode pratique pour en creer une.
Commencez par ce qui se fait deja
Demandez a votre equipe : "Que faisons-nous deja avant de considerer quelque chose comme termine ?" Notez chaque reponse. La plupart des equipes ont deja des standards informels qui n'ont pas ete documentes.
Identifiez les lacunes
Examinez les bugs recents ou les incidents de production. Qu'est-ce qui aurait pu les detecter plus tot ? Ces lacunes deviennent des candidats pour de nouveaux elements de la DoD.
Restez concis
Visez 6 a 12 elements. Chaque element doit meriter sa place en prevenant une vraie categorie de probleme. Si vous ne pouvez pas pointer un probleme specifique qu'un element detecterait, supprimez-le.
Rendez-la visible
Affichez la DoD la ou l'equipe peut la voir pendant le sprint planning et le travail quotidien. Une checklist enterree dans un wiki est une checklist que personne ne lit.
Revisez-la a chaque retrospective
Ajoutez un point permanent a l'ordre du jour de vos retros. Demandez : "La DoD a-t-elle detecte ce qu'il fallait ? Est-ce que quelque chose est passe entre les mailles ? Faut-il ajouter ou supprimer des elements ?"

Ce que font differemment les equipes performantes

Les recherches de Ron Lichty revelent un schema clair. Les equipes performantes sont proprietaires de leur DoD et la font evoluer deliberement. Elles l'utilisent aussi pour garder des estimations honnetes plutot qu'optimistes. Ces equipes automatisent autant d'elements de la checklist que possible. Les verifications de couverture de code et l'analyse statique s'executent dans les pipelines CI/CD en meme temps que les analyses de securite. La DoD est appliquee par le systeme plutot que par la memoire, ce qui libere l'equipe pour se concentrer sur les elements qui necessitent vraiment un jugement humain, comme savoir si les criteres d'acceptation sont remplis du point de vue de l'utilisateur. Les equipes les plus matures lient leur DoD aux resultats business, pas seulement aux standards techniques. Martin Hinshelwood donne un exemple : "En production, collectant de la telemetrie, confirmant ou infirmant l'hypothese de depart." C'est une equipe dont la definition of done n'est pas seulement "le code fonctionne" mais "nous apprenons de ce que nous avons livre."

Pour commencer

Choisissez trois elements de la checklist debutant ci-dessus. Ecrivez-les sur un tableau blanc ou ajoutez-les dans un document partage. Utilisez-les pendant un sprint. Lors de la retro, demandez ce qui a fonctionne et ce qui manque. Ajoutez un ou deux elements. Repetez. Une DoD petite et constante que l'equipe suit reellement vaut mieux qu'une DoD exhaustive que tout le monde ignore. Construisez d'abord l'habitude, puis relevez la barre. Et la prochaine fois que quelqu'un demande si une story est terminee, vous aurez une reponse qui ne necessite pas une conversation de 10 minutes. Si votre equipe utilise le planning poker pour l'estimation, gardez la DoD visible pendant ces sessions. C'est le moyen le plus rapide de s'assurer que les estimations refletent le perimetre complet de ce que "termine" signifie reellement.

Revisez-la a chaque retrospective de sprint. La plupart du temps vous ne changerez rien, mais l'habitude la maintient pertinente. Mettez-la a jour quand vous trouvez des lacunes de qualite recurrentes ou quand de nouveaux outils rendent des elements existants automatisables.

Le Scrum Guide dit que si une organisation a une DoD standard, les equipes doivent la suivre comme minimum. Les equipes peuvent ajouter des standards plus stricts par-dessus. En pratique, chaque equipe devrait etre proprietaire des elements au-dela du socle organisationnel.

La Definition of Ready couvre si un element du backlog dispose d'assez d'informations pour commencer le travail (exigences claires, dependances identifiees). La Definition of Done couvre si le travail termine repond aux standards de qualite. La Ready est la porte d'entree, la Done est la porte de sortie.

Non. Si elle ne respecte pas la DoD complete, elle n'est pas terminee. Elle retourne dans le product backlog. Le travail partiellement termine ne doit jamais etre presente en sprint review ni compte dans la velocite.
Dernière mise à jour le 10/02/2026