Une Definition of Ready (DoR) et une Definition of Done (DoD) : deux accords qualité distincts, deux portes que chaque user story doit franchir dans un sprint Scrum. La plupart des équipes connaissent la DoD — elles ignorent ou bâclent cette pratique. C'est précisément là que les sprints se dérèglent : des stories floues entrent en sprint planning, personne ne s'entend sur ce qu'elles signifient, et le sprint commence sur des sables mouvants.
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) — liste des critères qu'une story doit satisfaire pour sortir du sprint comme "terminée". Elle est vérifiée lors de la sprint review — 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) | Après le sprint (sprint review) |
| Question | "Cette story est-elle prête à démarrer ?" | "Cette story est-elle vraiment terminée ?" |
| Responsable | Product Owner (prépare), équipe (valide) | Équipe de développement (applique), PO (valide) |
| Porte sur | La clarté et la faisabilité | La qualité et la complétude |
| Si non respectée | Story reportée au backlog, non sélectionnée | 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 : une story qui ne remplit pas ces critères au moment du sprint planning est reportée au sprint suivant, sans exception. Le coût immédiat (story reportée) est toujours inférieur au coût différé (sprint déstabilisé par une story floue).
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
Dans Manifst, chaque user story dispose d'une checklist de critères d'acceptation intégrée. Cette checklist sert les deux usages : le PO peut y documenter les conditions de la DoR (ce que la story doit clarifier avant d'entrer en sprint), et l'équipe peut y suivre les points de la DoD story par story pendant le développement.
Lors du sprint planning dans Manifst, les stories candidates sont visibles avec leurs critères et leur estimation : le Scrum Master et le PO peuvent vérifier en un coup d'œil si chaque story satisfait la DoR avant de l'intégrer au sprint. La Definition of Done de projet est quant à elle documentée dans les paramètres et reste accessible depuis le kanban tout au long du sprint.
Essayez Manifst gratuitement — 1 projet, 4 membres, toutes les fonctionnalités incluses, sans carte bancaire.