Definition of Done (DoD) et Definition of Ready (DoR) dans Scrum : Maîtriser les Engagements de Qualité et de Flux
Cet article fait partie de notre Le Guide Ultime de Scrum : Maîtriser le Framework Agile de A à Z.
Dans le monde du développement agile, la confusion entre ce qui est « prêt à être commencé » et ce qui est « réellement terminé » est l’une des causes principales de friction au sein des équipes. Combien de Sprints se terminent par des fonctionnalités presque achevées, du code non testé ou des dettes techniques accumulées sous prétexte que « le plus gros est fait » ? Pour remédier à ces dérives, les praticiens s’appuient sur deux concepts clés : la Definition of Done (DoD) et la Definition of Ready (DoR). Si leurs noms se ressemblent, leurs rôles, leurs statuts formels dans le framework Scrum et leur impact sur le quotidien de l’équipe sont profondément différents. Conçus à l’origine par Jeff Sutherland et Ken Schwaber dans le Scrum Guide, les engagements agiles visent avant tout à créer de la transparence et à instaurer une confiance durable. Découvrons ensemble comment faire de ces deux outils de véritables leviers de performance plutôt que des contraintes bureaucratiques.
La Definition of Done (DoD) : L’engagement qualité officiel de Scrum
Dans la version actuelle du Scrum Guide, la Definition of Done (DoD) n’est pas une simple checklist optionnelle : c’est l’engagement formel associé à l’un des trois artefacts majeurs de Scrum, l’Incrément. Elle représente une description formelle et partagée de ce que signifie l’état « Terminé » pour le produit. Dès lors qu’un élément du Product Backlog répond à la Definition of Done, il donne naissance à un Incrément utilisable et livrable.
Un rôle central de transparence et de responsabilité
La DoD crée une compréhension commune et sans ambiguïté du travail accompli. Sans elle, le Product Owner, les parties prenantes et l’équipe de développement risquent d’avoir des interprétations divergentes de ce qu’est une fonctionnalité livrée. Dans Scrum, la responsabilité du respect et du maintien de la Definition of Done incombe directement aux Développeurs. Ce sont eux qui garantissent le niveau de qualité technique nécessaire pour maintenir le produit stable, sécurisé et évolutif.
Exemples concrets de critères typiques d’une DoD
Selon la nature de votre produit (application web, logiciel embarqué, service cloud ou projet d’infrastructure), la DoD comporte des critères d’exigence technique et fonctionnelle bien précis. Voici les exemples les plus fréquents dans une équipe de développement informatique :
- Revue de code : Le code a été relu et approuvé par au moins un autre développeur (peer review).
- Couverture de tests : Les tests unitaires et d’intégration ont été écrits, exécutés et passent tous au vert avec succès.
- Intégration continue : Le code est fusionné dans la branche principale (main/master) sans casser le build automatisé.
- Documentation : La documentation technique, le guide utilisateur ou les notes de version (release notes) sont mis à jour.
- Déploiement : La fonctionnalité est déployée sur un environnement de recette/staging automatisé et vérifiée.
- Conformité : Les critères de sécurité, de performance et d’accessibilité (RGAA/WCAG) sont validés.
Évolution et maturité de l’équipe
La Definition of Done n’est jamais gravée dans le marbre. Au lancement d’un projet ou d’une nouvelle équipe, la DoD peut être relativement simple pour s’adapter aux capacités du moment. Cependant, au fur et à mesure que l’équipe gagne en maturité, automatise ses déploiements et intègre des pratiques inspirées d’outils comme Extreme Programming ou Lean, la DoD s’enrichit. Une équipe chevronnée y ajoutera par exemple l’exécution automatique de tests de charge ou la validation automatisée des vulnérabilités de sécurité.
Que se passe-t-il quand un élément ne respecte pas la DoD ?
La règle édictée par le Scrum Guide est d’une clarté absolue : si un élément du Product Backlog ne répond pas à la Definition of Done, il ne peut pas être présenté lors de la Sprint Review, ni être comptabilisé dans l’Incrément. Il n’existe pas de fonctionnalité « livrée à 90 % » ou « presque finie ». Si le travail est incomplet au terme du Sprint, l’élément retourne directement au Product Backlog. Le Product Owner pourra alors le réévaluer, le réordonner et le proposer pour un Sprint ultérieur. Cette intransigeance est indispensable pour éviter l’accumulation invisible de dette technique.
La Definition of Ready (DoR) : Pratique populaire mais NON formalisée
Alors que la DoD est un pilier constitutif de Scrum, la Definition of Ready (DoR) occupe un statut totalement différent. Il est fondamental d’être honnête sur cette nuance : la DoR n’est PAS formalisée ni prescrite par le Scrum Guide. Elle constitue en réalité une pratique courante issue de la communauté agile, largement diffusée dans des cadres complémentaires ou des organisations appliquant Kanban ou SAFe.
Qu’est-ce qu’une User Story « prête » ?
La Definition of Ready définit l’ensemble des critères qu’un élément du Product Backlog (souvent rédigé sous forme de User Story) doit remplir avant de pouvoir être sélectionné lors du Sprint Planning. L’objectif initial de la DoR est de s’assurer que l’équipe ne s’engage pas sur du travail trop flou, mal compris ou dépendant d’éléments externes non maîtrisés.
Les critères typiques d’une DoR
Une Definition of Ready efficace s’appuie souvent sur des principes pragmatiques (comme le modèle INVEST formalisé dans les travaux de référence d’auteurs agiles comme Mike Cohn). On y retrouve généralement :
- Un besoin métier clair : Le « Pourquoi » et le « Pour qui » sont clairement exprimés par le Product Owner.
- Des critères d’acceptation précis : Les conditions de validation fonctionnelle sont rédigées et comprises par tous (souvent au format Given/When/Then).
- Une taille maîtrisée : L’élément est suffisamment petit pour être réalisé sereinement au cours d’un seul Sprint.
- L’absence de dépendances bloquantes : Les maquettes UX/UI, l’accès aux API tierces ou les prérequis techniques sont disponibles.
- Une estimation réalisée : L’équipe a pu discuter de l’élément et en évaluer la complexité ou l’effort.
Pièges et erreurs fréquents autour de la DoD et de la DoR
Malgré leurs bénéfices évidents, la mise en œuvre de ces deux définitions donne souvent lieu à des dérives méthodologiques qui ralentissent les équipes au lieu de les aider.
Erreur 1 : La DoD trop vague ou jamais vérifiée
C’est le piège classique des équipes débutantes : concevoir une DoD très théorique, rédigée sur une page Confluence lors du lancement du projet, mais ne jamais s’y référer lors des réunions quotidiennes (Daily Scrum) ou de la fin de Sprint. Résultat : « Terminé » continue de signifier « ça marche sur mon poste ». La recette s’éternise, les bugs explosent en production et l’Incrément réel n’est jamais stabilisé.
Erreur 2 : La DoR transformée en « Stage Gate » bureaucratisé
C’est le travers inverse, extrêmement fréquent avec la DoR. Lorsque les Développeurs utilisent la DoR comme un bouclier pour refuser systématiquement tout sujet sous prétexte qu’il manque le moindre détail, la DoR devient un contrat rigide. On assiste alors à une dérive vers un cycle en cascade (mini-waterfall) déguisé : le Product Owner doit rédiger des spécifications ultra-détaillées des semaines à l’avance. Le flux de travail s’interrompt, l’échange direct disparaît et l’agilité s’effondre.
Erreur 3 : L’absence de réévaluation collective
Garder une DoD ou une DoR figée pendant plusieurs mois sans jamais les interroger en Rétrospective de Sprint empêche l’équipe de progresser. La DoD doit se renforcer au rythme de l’apprentissage technique, tandis que la DoR doit s’alléger au fur et à mesure que la confiance et la collaboration entre le Product Owner et les Développeurs s’intensifient.
Conseils pratiques pour co-construire votre DoD et votre DoR avec l’équipe
Pour faire de la DoD et de la DoR de véritables outils de facilitation au quotidien, voici une démarche éprouvée à mettre en œuvre lors de vos ateliers d’équipe :
- Animer un atelier collaboratif initial : Rassemblez toute l’équipe Scrum (Product Owner, Scrum Master et Développeurs) autour d’un tableau blanc interactif comme Miro, ou dans votre outil de gestion comme Jira, Trello ou Azure DevOps. Posez deux questions simples : « De quoi avons-nous collectivement besoin pour démarrer une tâche sans être bloqués ? » (DoR) et « Quelles sont les étapes indispensables pour garantir qu’un morceau de code est prêt pour la production ? » (DoD).
- Viser le pragmatisme et le réalisme : Il vaut mieux une DoD courte de 4 critères réellement appliqués à 100 % à chaque Sprint qu’une liste idéale de 20 critères inapplicables qui génèrent du mensonge organisationnel.
- Utiliser la DoR comme un guide de conversation : La DoR ne doit pas être une grille de notation froide, mais une trame de discussion lors des séances de refinement du Product Backlog. Si un critère manque, demandez-vous ensemble si cela empêche réellement de démarrer ou si l’équipe peut clarifier le point en début de Sprint.
- Faire évoluer les définitions en Rétrospective : Si des bugs récurrents apparaissent en production, demandez-vous quel critère manque à votre DoD pour bloquer ces anomalies à l’avenir. Inversement, si le Sprint Planning s’éternise, vérifiez si votre DoR n’est pas trop lourde.
- Aligner la DoD avec les standards de l’organisation : Si votre entreprise possède des normes d’ingénierie globale (certifications Scrum.org ou Scrum Alliance, politiques de sécurité CI/CD), assurez-vous que la DoD de l’équipe respecte au minimum ce socle commun.
Pour aller plus loin
Pour approfondir ces concepts et perfectionner la gestion de la qualité et du backlog au sein de vos équipes, voici trois ouvrages incontournables recommandés par la rédaction :
- Scrum : Un outil convivial pour une agilité radicale par Claude Aubry (Éditions Dunod) : L’ouvrage francophone de référence pour appréhender Scrum dans toute sa dimension vivante et pragmatique, avec un éclairage très clair sur l’élaboration de la Definition of Done.
- User Stories Applied: For Agile Software Development par Mike Cohn (Addison-Wesley) : La bible du découpage d’exigences en User Stories, parfaite pour comprendre comment amener vos éléments de backlog à un état « prêt » sans tomber dans la sur-spécification.
- Gestion de projet agile : avec Scrum, Lean, eXtreme Programming… par Véronique Messager (Éditions Eyrolles) : Un guide pratique pour orchestrer la qualité, l’amélioration continue et la synergie entre les différents rôles de l’équipe projet.
En résumé, rappelez-vous que la Definition of Done est votre bouclier qualité pour protéger le produit à long terme, tandis que la Definition of Ready est une boussole pour fluidifier vos échanges lors de l’affinage du backlog. Utilisées avec mesure et esprit d’équipe, elles apportent la sérénité nécessaire au succès de vos Sprints.
Et vous, quelle est la règle la plus importante figurant dans la Definition of Done de votre équipe ? Avez-vous déjà vu une Definition of Ready paralyser votre Sprint Planning ? Partagez vos retours d’expérience et vos anecdotes dans les commentaires ci-dessous !
Photo : Ketut Subiyanto sur Pexels.
Pour aller plus loin
Liens affiliés Amazon : en tant que Partenaire Amazon, ce site perçoit une commission sur les achats éligibles réalisés via ces liens, sans coût supplémentaire pour vous.
Un ouvrage francophone de référence pour maîtriser les artefacts Scrum, structurer l’exigence qualité et mettre en place une Definition of Done pragmatique.
User Stories Applied: For Agile Software Development, Mike Cohn
Le livre incontournable pour rédiger des critères d’acceptation de qualité et qualifier le Product Backlog sans tomber dans les pièges de la bureaucratie.
Un guide pragmatique qui explique comment faire coopérer les rôles et intégrer l’amélioration continue au sein de la démarche agile.
Autres ressources sur l’agilité
- Les cérémonies Scrum : le guide complet pour rythmer vos Sprints
- Glossaire Scrum : tous les termes de l’agilité expliqués
- La Méthode Scrum
- Le scrum master : un rôle déterminant de l’agilité
- Les Méthodes Agiles
