La Definition of Ready (DoR) et la Definition of Done (DoD) ne jouent pas au même niveau. La DoR est une convention facultative choisie par certaines équipes pour préparer les échanges du Sprint Planning. La DoD, elle, fait partie de Scrum et décrit l'état de qualité requis pour qu'un travail appartienne à l'Increment. Les confondre transforme facilement un repère de discussion en porte administrative.
Cet article couvre la Definition of Ready en profondeur : sa définition, ses critères, ses erreurs et la façon dont elle s'articule avec la DoD. Pour la DoD seule, consultez notre guide Definition of Done Scrum : guide complet et exemples.
Definition of Ready vs Definition of Done : la réponse courte
Definition of Ready (DoR) - liste des conditions qu'une user story doit remplir pour entrer en sprint. Elle est vérifiée en sprint planning.
Definition of Done (DoD) - description formelle de l'état de l'Increment lorsqu'il respecte les mesures de qualité du produit. Sa conformité se vérifie pendant le travail ; la sprint review inspecte ensuite le résultat et les adaptations possibles. La DoD est une exigence du Guide Scrum 2020.
Une story entre par la porte de gauche. Elle sort par la porte DoD. Entre les deux : le sprint.
Tableau comparatif DoR vs DoD
| Definition of Ready (DoR) | Definition of Done (DoD) | |
|---|---|---|
| Moment de vérification | Avant le sprint (sprint planning) | Pendant le travail, avant d'intégrer l'Increment |
| Question | "Cette story est-elle prête à démarrer ?" | "Cette story est-elle vraiment terminée ?" |
| Responsable | Convention élaborée collectivement ; le PO clarifie et ordonne le backlog | Scrum Team (définit si aucun standard supérieur), Developers (respectent) |
| Porte sur | La clarté et la faisabilité | La qualité et la complétude |
| Si non respectée | Item clarifié, découpé ou non sélectionné selon le risque | Story non comptabilisée comme terminée |
| Révisée lors de | Backlog grooming, rétrospective | Rétrospective |
La Definition of Ready en détail
Définition et origine
La Definition of Ready est un concept complémentaire à la DoD, formalisé pour répondre à un problème récurrent : des stories arrivent en sprint planning sans que personne ne soit vraiment capable de les développer. Le Product Owner les a ajoutées au backlog, peut-être estimées lors d'un grooming, mais les développeurs ont des questions fondamentales sans réponse. Le sprint planning dure deux heures de plus que prévu. Le sprint démarre en retard avec des stories floues.
C'est la solution à ce problème. Elle définit le niveau minimum de préparation qu'une story doit atteindre pour être eligible à un sprint. Elle ne garantit pas que la story sera sélectionnée : elle garantit que si elle est sélectionnée, l'équipe a tout ce qu'il faut pour la commencer sans ambiguïté.
Ce que la DoR n'est pas
Ce n'est pas une spécification fonctionnelle exhaustive. Ce n'est pas un cahier des charges. Ce n'est pas un document de 10 pages. C'est une liste de contrôle légère : 4 à 7 critères au maximum : qui confirme qu'une story est actionnable.
Une checklist d'entrée trop détaillée génère plus de problèmes qu'elle n'en résout : le PO passe son temps à documenter plutôt qu'à prioriser, et l'équipe perd l'agilité qu'elle est censée avoir. Le juste milieu : assez de clarté pour commencer, assez d'espace pour découvrir en cours de route.
Exemple de Definition of Ready : 5 critères de base
Voici une DoR applicable à la grande majorité des équipes Scrum pratiquant du développement logiciel :
- Format user story respecté - rédigée au format "En tant que / Je veux / Afin de", avec un rôle utilisateur identifiable.
- Critères d'acceptation écrits - au moins 2 à 3 critères clairs, testables, validés par le PO. Une story sans critères d'acceptation n'est pas prête.
- Estimée par l'équipe - story points attribués lors d'une session de backlog grooming. Une story non estimée ou dont l'estimation dépasse 13 points (non découpée) n'est pas prête.
- Dépendances identifiées et non bloquantes - si la story dépend d'une API tierce, d'une autre équipe ou d'une décision métier, ces dépendances sont explicites et non bloquantes au moment de démarrer.
- Maquette ou spécification disponible si nécessaire - pour les stories impliquant une UI ou une logique complexe, la maquette est validée ou la spécification technique est écrite.
Adapter la DoR au type de story
Toutes les stories ne sont pas des features. La DoR doit s'adapter :
| Type | Critères spécifiques à la DoR |
|---|---|
| Feature | DoR standard (5 critères ci-dessus) |
| Bug | Reproduction documentée, environnement affecté précisé, criticité définie |
| Spike (exploration) | Question à répondre clairement formulée, durée bornée (timeboxed), livrable attendu défini |
| Dette technique | Problème actuel décrit (pas "améliorer le code"), impact sur les features futures expliqué |
La session 3 Amigos : valider la DoR avant le sprint planning
La technique des 3 Amigos est la pratique la plus efficace pour s'assurer qu'une story remplit la DoR avant d'entrer en sprint planning. Le principe : réunir trois perspectives différentes sur la même story.
- Le Product Owner - apporte le quoi et le pourquoi métier
- Un développeur - apporte la perspective technique (comment)
- Un testeur ou QA - apporte la perspective qualité (comment vérifier)
Ensemble, ils passent en revue la story et ses critères d'acceptation. Si les trois arrivent à s'entendre sur ce que "terminé" signifie pour cette story, elle est prête. Si l'un des trois a des questions sans réponse, la story retourne au PO pour clarification.
Une session 3 Amigos dure 15 à 20 minutes par story. Elle se tient lors du backlog grooming, pas en sprint planning. L'objectif : que le sprint planning ne soit jamais une réunion de clarification.
Le flux qualité complet : DoR → Sprint → DoD
La DoR et la DoD ne sont pas deux concepts indépendants : elles forment les deux extrémités d'un cycle qualité continu :
- Product Backlog - stories brutes, non qualifiées
- Backlog grooming - le PO et l'équipe raffinent, estiment, appliquent la DoR
- Sprint Planning - seules les stories "DoR compliant" sont sélectionnables
- Développement (sprint) - l'équipe travaille en ayant la DoD en tête à chaque story
- Sprint Review - les stories sont acceptées uniquement si la DoD est satisfaite
- Rétrospective - DoR et DoD sont révisées si des problèmes ont été détectés
Sans DoR, l'étape 3 est un goulot d'étranglement : le sprint planning s'éternise sur des stories incomplètes. Sans DoD, l'étape 5 est floue : les parties prenantes ne savent pas ce qu'elles valident. Les deux ensemble créent un système qualité auto-régulé, sprint après sprint.
Les erreurs courantes sur la Definition of Ready
1. La DoR trop détaillée
Certaines équipes, traumatisées par des sprints chaotiques, construisent une checklist de 15 critères. Résultat : le PO passe sa semaine à documenter pour satisfaire une checklist administrative. Les stories arrivent au sprint planning avec une checklist formellement complète mais sans vraie valeur ajoutée. La DoR doit être un filet de sécurité, pas une bureaucratie.
Règle pratique : si votre PO passe plus de 30 minutes à préparer une seule story pour satisfaire cette liste de contrôle, elle est trop lourde.
2. La DoR appliquée sous pression
"On a besoin de cette story dans le sprint, on l'intégrera quand même." Ce contournement est le signe d'une pratique qui n'a pas le soutien du management ou du PO. Un accord que l'équipe accepte de contourner sous pression ne protège personne : elle crée une fausse sécurité pire que l'absence de tout critère d'entrée.
La discipline utile consiste à ne pas sélectionner un item que l'équipe comprend insuffisamment pour construire un plan crédible. La DoR reste toutefois une convention d'équipe, pas une porte officielle imposée par Scrum : un item peut encore être clarifié et décomposé pendant le Sprint Planning si l'équipe estime le risque acceptable.
3. Confondre DoR et DoD
Ajouter des critères techniques dans cette liste ("le code doit être testé") est une erreur fréquente. La DoR porte sur la préparation (peut-on commencer ?), pas sur la qualité de livraison (a-t-on bien fini ?). Mélanger les deux crée de la confusion sur qui vérifie quoi et quand.
4. Ne jamais réviser la DoR
Une checklist construite le premier mois d'une équipe et jamais touchée depuis est probablement inadaptée. Une équipe junior a besoin de critères plus stricts (maquette obligatoire, critères plus détaillés). Une équipe senior peut fonctionner avec une liste de contrôle plus légère car le niveau de confiance et d'alignement est plus élevé.
La rétrospective est le moment naturel pour la réviser : "Ce sprint, y a-t-il eu des stories qui auraient dû être bloquées par notre DoR mais ne l'ont pas été ?"
DoR, DoD et maturité de l'équipe
Le niveau de formalisme de la DoR doit s'adapter à la maturité de l'équipe :
- Équipe débutante (0-6 mois de Scrum) - DoR stricte et détaillée. Les ambiguïtés coûtent cher à ce stade car l'équipe ne sait pas encore improviser. Chaque critère absent en sprint planning génère du blocage.
- Équipe intermédiaire (6-18 mois) - DoR standard (5 critères de base). L'équipe commence à avoir des réflexes, elle peut gérer une légère ambiguïté sans se paralyser.
- Équipe mature (18+ mois) - DoR allégée. La confiance est établie entre PO et développeurs. Certains critères formels deviennent implicites. Elle peut se réduire à 2-3 critères non négociables.
L'erreur inverse existe aussi : maintenir une checklist très légère avec une équipe débutante par volonté de "rester agile". L'agilité ne signifie pas l'absence de structure : elle signifie la structure juste.
Definition of Ready et Definition of Done dans Manifst
Chaque ticket Manifst possède une liste de critères d'acceptation. L'équipe peut s'en servir pour vérifier qu'elle partage la même compréhension avant le sprint, mais Manifst ne bloque pas automatiquement un ticket au motif qu'il ne serait pas « ready ».
Pendant le planning, les tickets candidats affichent leur statut, leurs critères et leur estimation. Les éléments non estimés et les risques de surcharge sont signalés ; la décision d'embarquer un ticket reste collective.
La Definition of Done est configurée dans les paramètres du projet. Elle est copiée dans le planning du sprint, peut y être adaptée et figure dans le récapitulatif du sprint. Elle n'est pas actuellement affichée dans le kanban. Voir la préparation des sprints dans Manifst.
Essayez Manifst gratuitement : 1 projet, 5 membres, sans carte bancaire ; budget EVM inclus.