Une fonctionnalité marquée « Done » dans Jira, mais qui revient en bug deux sprints plus tard , ça vous parle ? C’est exactement le problème que la Definition of Done est conçue à résoudre. Dans beaucoup d’équipes Agile et Scrum, « terminé » veut dire quelque chose de différent selon qui parle : pour le dev, c’est codé ; pour le QA, c’est testé ; pour le Product Manager, c’est livrable. Ce flou crée des bugs, des retards, des incompréhensions et une dette technique qui s’accumule sprint après sprint. La Definition of Done, c’est le contrat interne de l’équipe , la liste précise des critères qu’une fonctionnalité doit remplir pour être réellement considérée comme terminée. On va voir exactement ce qu’est la Definition of Done, pourquoi elle est non négociable dans une organisation Agile sérieuse, et comment la construire et l’appliquer concrètement dès votre prochain sprint.
En bref :
- ● La Definition of Done (DoD) est une liste de critères que chaque incrément produit doit satisfaire avant d’être considéré comme terminé.
- ● Elle est créée dès le premier Sprint par l’équipe Scrum, idéalement lors du Sprint Planning.
- ● La Definition of Done est distincte des critères d’acceptation : elle s’applique à tous les éléments du Backlog, pas à un seul.
- ● Elle couvre typiquement : code review, tests, documentation, déploiement et validation qualité.
- ● Une Definition of Done mal définie est l’une des principales causes de dette technique et de livraisons incomplètes.
- ● Dans les frameworks SAFe ou à grande échelle, la Definition of Done s’applique à plusieurs niveaux : Story, Feature, Solution.
- ● Des outils comme Jira ou Confluence (Atlassian) permettent de formaliser et de suivre la Definition of Done en équipe.
DOD Definition of Done : que signifie vraiment cette notion ?
Soyons clairs. Dans la plupart des équipes Agile, le mot « terminé » ne veut pas dire la même chose pour tout le monde. Un développeur pense que c’est terminé quand le code compile. Le Product Owner pense que c’est terminé quand le client peut l’utiliser. Le testeur, lui, attend encore les tests de régression. Résultat : des livraisons bancales, de la dette technique qui s’accumule, et une équipe qui tourne en rond.
C’est exactement pour ça que la Definition of Done (DoD) existe.
La Definition of Done est une liste de critères formels, partagés et acceptés par toute l’équipe, qui définit précisément ce que signifie « terminé » pour un incrément de produit. Ce n’est pas une opinion. Ce n’est pas une préférence personnelle. C’est un contrat interne à l’équipe.
Le concept est officiellement ancré dans le Scrum Guide 2020, qui précise que la Definition of Done est un engagement formel des Developers pour garantir la qualité de chaque incrément. Ce guide, publié par Ken Schwaber et Jeff Sutherland, est la référence absolue du framework Scrum.
Point important : la Definition of Done s’applique à chaque élément du Product Backlog, pas uniquement à une user story isolée. Dès qu’un item du Backlog est travaillé, la Definition of Done s’applique. Sans exception.
Un exemple simple : une équipe software décide que pour qu’une fonctionnalité soit « done », il faut que le code soit reviewé par un pair, que les tests unitaires couvrent au moins 80 % du code, et que la documentation soit mise à jour. Chaque fois. Sans négociation.
| Aspect | Sans Definition of Done | Avec Definition of Done |
|---|---|---|
| Qualité | Variable selon les membres | Homogène et prévisible |
| Communication | Ambiguïtés fréquentes | Référentiel commun clair |
| Livraison | Incomplète ou instable | Fiable et validée |
| Dette technique | S’accumule rapidement | Maîtrisée et limitée |
⚠️ Attention , Piège classique
La Definition of Done n’est pas la même chose que les critères d’acceptation. Les critères d’acceptation sont spécifiques à une user story particulière (« en tant qu’utilisateur, je peux me connecter avec mon email »). La Definition of Done, elle, s’applique à tous les éléments du Backlog, systématiquement. Confondre les deux, c’est s’exposer à des livraisons incohérentes et à des incompréhensions entre le Product Owner et les Developers.
Pourquoi la Definition of Done change tout en Agile
Sans Definition of Done formalisée, chaque membre de l’équipe travaille avec sa propre définition de « terminé ». C’est invisible au quotidien, mais dévastateur sur la durée. Les malentendus s’accumulent, les bugs reviennent, et la confiance entre l’équipe et les parties prenantes s’érode progressivement.
Dès qu’une Definition of Done claire existe, la transparence devient réelle. Tout le monde sait exactement où en est le travail. Pas d’interprétation, pas de zone grise. C’est l’un des piliers fondamentaux de l’approche Agile : inspecter et adapter sur une base factuelle.
Le Scrum Master joue un rôle clé ici. Son rôle n’est pas de créer la Definition of Done à la place de l’équipe, mais de s’assurer qu’elle existe, qu’elle est respectée, et qu’elle évolue. Il coache l’équipe pour que la Definition of Done devienne un réflexe, pas une contrainte. Les équipes dotées d’une Definition of Done formelle livrent des incréments de qualité significativement plus stable que celles qui n’en ont pas.
Comment et quand la DOD Definition of Done est-elle créée dans un projet ?
Bonne nouvelle : la Definition of Done n’appartient à personne en particulier. Elle est créée collectivement par l’équipe Scrum dans son ensemble , les Developers, le Scrum Master et le Product Owner. Chacun apporte sa perspective. Les Developers savent ce qui est techniquement nécessaire. Le Product Owner connaît les attentes métier. Le Scrum Master facilite la conversation.
Ce point est crucial : le Scrum Master facilite, il ne dicte pas. Il pose les bonnes questions, structure la discussion, et s’assure que la Definition of Done est réaliste et atteignable. Mais ce sont les Developers qui s’engagent dessus. Sans cet engagement, la Definition of Done reste un document mort.
Voici les étapes concrètes pour créer votre première Definition of Done :
- Réunir l’équipe Scrum complète lors du premier Sprint Planning , c’est le moment idéal pour poser les bases.
- Lister les critères qualité non négociables : qu’est-ce qui doit absolument être vrai pour qu’un incrément soit livrable ?
- Rédiger la Definition of Done sous forme de checklist simple, compréhensible par tous les membres de l’équipe.
- La documenter dans Confluence ou Jira pour qu’elle soit accessible à tout moment, visible et partagée.
- La valider collectivement , chaque membre de l’équipe doit pouvoir s’y engager sans réserve.
Dans les grandes organisations, la situation est un peu différente. La Definition of Done peut être partiellement imposée par l’organisation elle-même , notamment dans les contextes SAFe ou multi-équipes. L’équipe Scrum reçoit alors une Definition of Done de base qu’elle peut affiner et enrichir selon ses spécificités. Elle ne part pas de zéro, mais elle garde la main sur les critères qui lui sont propres.
💡 Conseil , Documenter la Definition of Done dans Confluence ou Jira
Créez une page dédiée dans Confluence avec la checklist de votre Definition of Done, liée directement à votre board Jira. Ajoutez cette page en lien dans chaque Sprint dans Jira pour qu’elle soit accessible en un clic. Certaines équipes vont plus loin et intègrent la Definition of Done directement dans les descriptions de tickets Jira via des templates automatiques , ce qui évite d’oublier de la consulter.
Quand réviser et mettre à jour la Definition of Done ?
La Definition of Done n’est pas gravée dans le marbre. Elle évolue. C’est même une des caractéristiques qui la rend puissante dans un contexte Scrum : elle s’adapte avec l’équipe.
Le moment naturel pour la réviser, c’est la Sprint Retrospective. À chaque fin de Sprint, l’équipe se pose la question : notre Definition of Done est-elle encore adaptée ? Faut-il ajouter ou retirer des critères ?
Plusieurs déclencheurs doivent alerter l’équipe :
- De nouvelles exigences qualité imposées par le client ou l’organisation
- Des retours clients révélant des lacunes récurrentes dans les livraisons
- Une dette technique détectée qui pointe vers un critère manquant dans la Definition of Done
- L’ajout d’un nouveau type d’élément au Backlog qui nécessite des critères spécifiques
Réviser la Definition of Done régulièrement, c’est un signe de maturité Agile. Pas de faiblesse.
Quels éléments concrets compose une DOD Definition of Done efficace ?
Parlons concret. Une Definition of Done vague ne sert à rien. « Le code est propre » , ça ne veut rien dire. Ce qui compte, c’est des critères précis, mesurables, et vérifiables par n’importe quel membre de l’équipe.
Voici les éléments qu’on retrouve le plus souvent dans une Definition of Done efficace pour une équipe software :
| Critère | Exemple concret |
|---|---|
| Code review validé | Au moins 1 pair a approuvé la pull request dans Jira/GitHub |
| Tests unitaires passés | Couverture de code ≥ 80 % sur les nouvelles fonctionnalités |
| Tests d’intégration | Tous les tests d’intégration passent en environnement CI/CD |
| Documentation mise à jour | README, Confluence ou wiki technique mis à jour dans les 24h |
| Déploiement en staging | L’incrément est déployé et fonctionnel en environnement de staging |
| Validation Product Owner | Le PO a confirmé que les critères d’acceptation sont satisfaits |
| Accessibilité vérifiée | Conformité WCAG 2.1 niveau AA vérifiée (score Lighthouse ≥ 90) |
| Performance testée | Temps de réponse API ≤ 200ms sous charge standard |
Des outils comme Jira (Atlassian) permettent d’automatiser une partie de ces vérifications. Avec Rovo Dev, l’assistant IA d’Atlassian intégré à Jira, certains checks peuvent être déclenchés automatiquement lors de la transition d’un ticket. Rovo AI peut également analyser le Backlog et suggérer des critères de Definition of Done manquants basés sur les patterns de bugs détectés , un gain de temps réel pour les équipes qui gèrent de gros volumes de tickets.
💡 Astuce , Par où commencer quand on démarre
Si votre équipe n’a pas encore de Definition of Done, ne cherchez pas la perfection dès le départ. Commencez avec 5 à 7 critères maximum, les plus impactants pour votre contexte. Ajoutez-en progressivement à chaque Sprint Retrospective. Une Definition of Done de 20 critères que personne ne respecte est moins utile qu’une Definition of Done de 6 critères appliqués rigoureusement à chaque sprint.
Exemple de Definition of Done pour une équipe software avec Jira
Voici un exemple réaliste de Definition of Done pour une équipe de développement logiciel utilisant Jira comme outil de management de projet :
- ✅ Code review : pull request approuvée par au moins 2 Developers dans Jira/Bitbucket
- ✅ Tests unitaires : couverture ≥ 80 % sur le nouveau code (rapport SonarQube attaché au ticket Jira)
- ✅ Tests d’intégration : pipeline CI/CD vert, zéro test en échec
- ✅ Documentation : page Confluence mise à jour ou créée, liée au ticket Jira
- ✅ Déploiement staging : fonctionnalité déployée et testée en environnement de pré-production
- ✅ Validation PO : ticket Jira passé en statut « Accepted » par le Product Owner
- ✅ Zéro bug bloquant : aucun bug de priorité P1 ou P2 ouvert sur le Backlog lié à cette story
Dans Jira, chaque critère peut être transformé en sous-tâche ou en champ de checklist sur le ticket. Cela permet de suivre l’avancement de la Definition of Done en temps réel, sans réunion supplémentaire. La Scrum board devient alors un vrai tableau de bord qualité, pas juste un outil de suivi de tâches.
Definition of Done vs Definition of Ready : quelle différence ?
C’est l’une des confusions les plus fréquentes dans les équipes Agile. Definition of Done et Definition of Ready , deux concepts proches, mais très différents. Les mélanger crée des blocages en sprint et des incompréhensions entre le Product Owner et les Developers.
Voici la distinction en une phrase : la Definition of Done définit quand une tâche est terminée. La Definition of Ready définit quand une tâche est prête à être travaillée.
Autrement dit : la Definition of Ready s’applique en amont du sprint, au moment du Backlog refinement. La Definition of Done s’applique en aval, quand l’équipe livre l’incrément.
| Critère | Definition of Done | Definition of Ready |
|---|---|---|
| Moment d’application | À la fin du travail, avant livraison | Avant le démarrage du sprint |
| Qui l’utilise ? | Toute l’équipe Scrum | Product Owner + Developers |
| Exemple de critère | Tests unitaires ≥ 80 % de couverture | User story rédigée avec critères d’acceptation |
| Objectif | Garantir la qualité de l’incrément livré | Garantir que la tâche est suffisamment claire pour être travaillée |
| Lié au Backlog ? | Oui, à chaque item livré | Oui, lors du refinement du Backlog |
Exemple concret : une user story « En tant qu’utilisateur, je peux réinitialiser mon mot de passe » est Ready quand elle a des critères d’acceptation clairs, une estimation en story points, et les maquettes associées. Elle est Done quand le code est reviewé, testé, documenté et déployé en staging.
Jira Product Discovery est particulièrement utile pour gérer la Definition of Ready côté product management. Il permet de structurer les idées et les opportunités avant qu’elles n’entrent dans le Backlog Scrum, en s’assurant que chaque item est suffisamment défini pour être actionnable.
⚠️ Attention , Ne pas confondre les deux
Une erreur classique : appliquer les critères de la Definition of Done au moment du refinement, ou utiliser la Definition of Ready comme condition de livraison. Les deux concepts jouent des rôles complémentaires mais distincts. Les confondre perturbe le flux du sprint et crée des blocages inutiles. Gardez-les séparés, documentez-les séparément dans Confluence, et référencez-les au bon moment dans le processus Agile.
Comment mettre en place la Definition of Done dans votre équipe Agile
Mettre en place une Definition of Done ne prend pas des semaines. Avec la bonne méthode, une équipe peut avoir sa première Definition of Done opérationnelle dès la fin de son premier Sprint Planning. Voici comment faire, étape par étape.
Étape 1 , Réunir l’équipe Scrum complète. Pas de Definition of Done sans tout le monde autour de la table. Developers, Scrum Master, Product Owner. Chacun apporte une perspective différente sur ce que signifie « terminé ». Prévoyez un atelier dédié d’une heure maximum.
Étape 2 , Lister les critères qualité non négociables. Posez une question simple à l’équipe : « Qu’est-ce qui doit absolument être vrai pour que vous soyez à l’aise de livrer cet incrément à un client ? » Notez tout. Filtrez ensuite. Une Definition of Done efficace contient entre 5 et 15 critères. En dessous, elle est trop légère. Au-dessus, elle devient ingérable.
Étape 3 , Construire une checklist de complétion. Transformez les critères en items vérifiables. Chaque critère doit pouvoir être coché : oui ou non. Pas de zone grise. Documentez cette checklist dans Confluence et liez-la à votre board Jira.
Étape 4 , Associer la Definition of Done aux user stories dans Jira. Utilisez les templates de tickets Jira pour intégrer la checklist Definition of Done directement dans chaque story du Backlog. Certaines équipes utilisent des champs personnalisés ou des automatisations Jira pour déclencher des rappels Definition of Done lors des transitions de statut. Dans un contexte Kanban, la Definition of Done s’applique à chaque carte qui passe en colonne « Done ».
Étape 5 , Réviser la Definition of Done à chaque Sprint Retrospective. La Definition of Done est vivante. À chaque rétro, demandez : « Un critère nous a-t-il manqué ce sprint ? Un critère est-il devenu obsolète ? » Ajustez en conséquence. C’est ce qui distingue une équipe Agile mature d’une équipe qui suit des process sans les comprendre.
Pour les contextes à grande échelle , SAFe, multi-équipes, ou Kanban à flux continu , la Definition of Done peut s’appliquer à plusieurs niveaux hiérarchiques : Story, Feature, Solution. Chaque niveau a ses propres critères, et ils se cumulent. Une Feature n’est « done » que si toutes les Stories qui la composent satisfont leur Definition of Done respective.
À noter : les principes de rigueur et de clarté qu’on applique à la Definition of Done s’exportent aussi dans d’autres domaines du digital. Que ce soit pour structurer un site web avec un CMS ou pour organiser une stratégie de contenu, définir des critères de complétion clairs fait toujours gagner du temps. De même, en référencement, des pratiques comme le maillage interne SEO reposent sur des règles précises et partagées , exactement comme une bonne Definition of Done.
Questions fréquentes sur la Definition of Done
Quelle est la différence entre la Definition of Done et les critères d’acceptation ?
Les deux notions sont souvent confondues, mais elles n’ont pas le même rôle. Les critères d’acceptation sont spécifiques à une User Story : ils définissent ce qu’attend le Product Owner pour valider cette fonctionnalité précise. La Definition of Done, elle, s’applique à toutes les stories et à tous les Incréments. C’est un standard d’équipe global , tests passés, code reviewé, documentation à jour , qui ne change pas d’une story à l’autre.
Combien de critères doit contenir une Definition of Done en Scrum ?
Il n’existe pas de nombre imposé. En pratique, une Definition of Done efficace contient entre 5 et 10 critères clairs et vérifiables. En dessous, elle manque de rigueur. Au-dessus, elle devient difficile à appliquer systématiquement. L’essentiel : chaque critère doit être binaire , fait ou pas fait. Une liste trop longue finit ignorée. Commencez simple, puis faites évoluer la Definition of Done au fil des Sprints lors des Rétrospectives.
La Definition of Done s’applique-t-elle aussi en Kanban ?
Oui, même si le concept est davantage associé à Scrum. En Kanban, la Definition of Done se traduit souvent par des critères de sortie de colonne : une tâche ne passe à l’étape suivante que si elle remplit des conditions précises. C’est la même logique , garantir qu’un travail est réellement terminé avant de passer à la suite. L’outil change, la discipline reste identique.
Comment Jira aide-t-il à gérer la Definition of Done ?
Jira permet d’intégrer la Definition of Done directement dans le flux de travail de l’équipe. On peut créer des checklists sur les tickets via des extensions comme Checklist for Jira, configurer des transitions conditionnelles entre statuts, ou relier chaque story à une page Confluence détaillant les critères. Résultat : la Definition of Done n’est plus un document oublié dans un coin , elle devient une étape obligatoire et visible à chaque ticket traité.
Que dit le Scrum Guide 2020 sur la Definition of Done ?
Le Scrum Guide 2020 positionne la Definition of Done comme un engagement formel de la Scrum Team envers la qualité de l’Incrément. Elle n’est plus optionnelle : si une organisation dispose déjà d’un standard de qualité, la Definition of Done doit au minimum le respecter, voire aller plus loin. Chaque Incrément livré doit satisfaire cette définition pour être considéré comme potentiellement livrable. C’est une responsabilité collective, pas individuelle.
Definition of Done : par où commencer concrètement dès votre prochain Sprint
La Definition of Done, c’est l’un de ces outils qui paraissent simples en surface, mais qui changent vraiment la façon dont une équipe travaille. Pas de magie là-dedans , juste un standard partagé, appliqué systématiquement, qui élimine les zones grises et les « c’est presque fini » qui traînent d’un Sprint à l’autre.
La prochaine étape concrète ? Organisez un atelier avec votre équipe Scrum , une heure suffit , pour définir ensemble vos 5 à 10 premiers critères. Partez de ce qui pose problème aujourd’hui : bugs en production, tests oubliés, documentation absente. Ce sont vos meilleurs indicateurs.
Pour formaliser tout ça, Confluence est idéal pour documenter et partager la Definition of Done à toute l’équipe. Jira permet de l’intégrer directement dans les tickets, pour qu’elle soit visible et vérifiable à chaque story traitée.
Ce que votre équipe gagne dès le prochain Sprint : moins de retours en arrière, des livraisons plus prévisibles, et une vraie culture de la qualité. Une Definition of Done claire, c’est moins de friction et plus de confiance , entre développeurs, Product Owner et parties prenantes. C’est ça, la vraie valeur.
