La Definition of Ready (DoR) est une pratique très répandue dans les équipes Scrum, mais paradoxalement absente du Scrum Guide. Ce guide complet est conçu pour devenir la meilleure ressource francophone sur la Definition of Ready et pour vous aider à réussir les questions PSM I qui s'y rapportent.
Qu'est-ce que la Definition of Ready ? Hors Scrum Guide 2020
La Definition of Ready est une liste partagée de critères qu'un Product Backlog Item (PBI) doit satisfaire avant d'être pris dans un Sprint Planning. Elle est utilisée pendant les sessions de refinement pour valider qu'un PBI est suffisamment préparé.
Concrètement, la DoR répond à la question : « cet item est-il assez clair, cadré et compris pour qu'on puisse raisonnablement le terminer pendant le prochain Sprint ? »
La DoR agit comme un filtre entre Product Backlog et Sprint Planning, mais n'est pas obligatoire.
Origine de la Definition of Ready
La Definition of Ready trouve ses racines dans la culture Extreme Programming (XP) et dans les premiers usages industriels de Scrum. Elle s'est popularisée à partir des années 2010 comme contrepoint à la Definition of Done : si la DoD garantit la sortie, la DoR a été conçue pour garantir l'entrée dans le Sprint.
Mike Cohn, Roman Pichler et d'autres figures de la communauté Agile ont contribué à la diffuser. Mais Ken Schwaber et Jeff Sutherland, auteurs du Scrum Guide, ont délibérément refusé de l'inclure dans le standard pour éviter qu'elle ne devienne une barrière administrative.
Pourquoi la DoR n'est PAS un élément officiel du Scrum Guide
Le Scrum Guide 2020 ne mentionne pas la Definition of Ready. Ce choix est conscient. Les raisons :
- Scrum repose sur la simplicité et le minimum nécessaire.
- Une DoR formelle peut devenir un contrat figé entre PO et Devs, contraire à la collaboration.
- Elle peut transformer Scrum en mini-cascade : « rien n'entre tant que tout n'est pas parfait ».
- Le refinement est déjà une activité continue prévue par le Scrum Guide ; la DoR fait double emploi si elle est mal utilisée.
- Scrum reconnaît la Definition of Done comme seul engagement de qualité (côté Increment).
Pourquoi de nombreuses équipes l'utilisent malgré tout
Si la DoR n'est pas officielle, elle reste très répandue. Ses bénéfices, quand elle est utilisée intelligemment :
- Réduire l'incertitude à l'entrée du Sprint.
- Fiabiliser le Sprint Planning et la prévision.
- Améliorer la qualité du Product Backlog.
- Aligner PO et Developers sur la même compréhension.
- Diminuer les retours en arrière en cours de Sprint.
- Faciliter la conversation autour des PBI complexes.
Objectifs principaux
| Objectif | En pratique |
|---|---|
| Réduire les incertitudes | Lever les ambiguïtés métier et techniques avant le Sprint |
| Améliorer le Sprint Planning | Sélectionner des PBI réellement actionnables |
| Qualité du Product Backlog | Maintenir un haut du backlog clair, priorisé, estimé |
| Préparer les PBI | Décomposer, clarifier, ajouter critères d'acceptation |
| Limiter les blocages en Sprint | Identifier dépendances et risques en amont |
| Renforcer l'alignement PO / Devs | Garantir une compréhension partagée du PBI |
Relation avec le Product Refinement
La DoR est le résultat naturel d'un refinement de qualité. Le Product Backlog Refinement est l'activité par laquelle la Scrum Team ajoute du détail, des estimations et de l'ordre aux PBI. Lorsque cette activité est bien menée, les PBI atteignent un état « Ready » sans qu'il soit nécessaire de formaliser une liste rigide.
La DoR concerne uniquement la transition Refinement → Ready.
Le Scrum Guide indique que le refinement « consiste à décomposer et définir plus finement les éléments du Product Backlog en éléments plus petits et plus précis. C'est une activité continue. » La DoR n'est qu'un indicateur que cette activité a abouti pour un PBI donné.
Relation avec le Sprint Planning
Pendant le Sprint Planning, la Scrum Team sélectionne les PBI qu'elle s'engage à terminer. Une DoR claire permet aux Developers d'évaluer plus sereinement ce qui peut entrer dans le Sprint.
Relation avec la Definition of Done
DoR et DoD sont souvent confondues. Pourtant, elles encadrent des moments opposés du cycle.
- Avant le Sprint
- Concerne l'entrée dans le Sprint
- Pratique optionnelle
- Non mentionnée dans le Scrum Guide
- Décidée par la Scrum Team
- À la sortie du Sprint
- Concerne la qualité de l'Increment
- Pratique obligatoire
- Définie par le Scrum Guide 2020
- Engagement de l'Increment
La DoR n'a aucune existence officielle dans Scrum. La DoD, en revanche, est un engagement du Scrum Guide.
Ready = avant le Sprint · Done = à la sortie du Sprint. Deux notions complémentaires.
Relation avec le Sprint Goal
Le Sprint Goal donne du sens au Sprint. La DoR ne doit jamais se substituer au Sprint Goal : la priorité reste la livraison de valeur. Un PBI « pas tout à fait Ready » mais essentiel au Sprint Goal peut très bien être pris si la Scrum Team décide collectivement qu'elle saura le clarifier au cours du Sprint.
La DoR vit dans la phase de Refinement, en amont du Sprint.
Critères classiques de Definition of Ready
Voici la checklist de critères les plus fréquemment utilisés par les équipes Scrum. Aucun n'est obligatoire : la Scrum Team choisit ce qui est utile à son contexte.
| Critère | Ce qu'il garantit |
|---|---|
| User Story claire | Le besoin est exprimé sans ambiguïté |
| Valeur métier comprise | L'impact pour l'utilisateur ou le produit est explicite |
| Critères d'acceptation définis | Conditions de succès vérifiables |
| Dépendances identifiées | Aucun blocage technique inconnu |
| Taille raisonnable | PBI réalisable dans un seul Sprint |
| Estimation réalisée | L'équipe a une vision de l'effort |
| Maquettes disponibles si nécessaire | L'UX est définie quand le PBI est visuel |
| Contraintes techniques connues | Architecture, perf, sécurité documentées |
| Risques identifiés | Inconnues et plan de mitigation |
| Testabilité | Critères d'acceptation testables, données disponibles |
Exemples de critères concrets
| Contexte | Exemple de critère DoR |
|---|---|
| Web e-commerce | Maquette Figma validée et critères d'acceptation rédigés |
| API backend | Contrat OpenAPI défini et exemples de payload présents |
| Mobile | Comportement précisé pour iOS et Android, états offline traités |
| Data / ML | Données disponibles, métriques de succès chiffrées |
| Bug | Étapes de reproduction stables, impact business évalué |
| Spike technique | Question précise, timebox définie, livrable attendu |
Risques d'une DoR trop rigide
Une DoR mal utilisée peut devenir contre-productive. Voici les principaux pièges à éviter.
| Risque | Conséquence |
|---|---|
| Contrat figé entre PO et Devs | Perte de collaboration, retour vers un mode cascade |
| Liste exhaustive de cases à cocher | Retard, bureaucratie, perte d'agilité |
| Refus systématique de PBI non Ready | Sprint Goal compromis, blocage de la valeur |
| Confusion DoR / DoD | Équipe perdue, qualité dégradée |
| DoR imposée par un manager | Équipe désresponsabilisée, perte d'auto-organisation |
| Aucune révision en Retrospective | DoR obsolète, déconnectée du contexte |
Bonnes pratiques / mauvaises pratiques
| Aspect | Bonne pratique | Mauvaise pratique |
|---|---|---|
| Création | Co-construite par la Scrum Team | Imposée par un manager ou un PO |
| Format | 5 à 8 critères clairs | Liste de 20 cases à cocher |
| Application | Indicateur, pas un mur | Refus systématique des PBI non Ready |
| Évolution | Révisée en Retrospective | Figée, jamais remise en cause |
| Portée | Adaptée au type de PBI | Une seule DoR universelle pour tout |
| Lien Sprint Goal | Sprint Goal prime sur DoR | DoR prime sur la valeur livrée |
| Refinement | Activité continue de qualité | Refinement remplacé par la DoR |
DoR légère vs DoR trop complexe
| Dimension | DoR légère (recommandée) | DoR trop complexe (à éviter) |
|---|---|---|
| Nombre de critères | 5 à 8 maximum | 15 à 30 critères |
| Niveau de détail | Critères orientés conversation | Spécifications complètes exigées |
| Souplesse | Indicateur, pas un blocage | Validation obligatoire avant Sprint |
| Responsabilité | Décidée par la Scrum Team | Imposée par la hiérarchie |
| Effet sur le Sprint | Sprint plus fluide | Backlog bloqué, valeur retardée |
| Compatibilité Scrum | Pleinement compatible | Risque de retour en cascade |
Exemple concret complet
Suivons un PBI sur l'application « Mobiloo » (location de scooters) à travers tout son parcours : avant DoR, application de la DoR, Sprint Planning, développement et passage à Done.
| Étape | Contenu |
|---|---|
| 1. PBI initial (avant Ready) | « En tant qu'utilisateur, je veux réserver un scooter. » Aucun critère, aucune maquette, valeur business floue. |
| 2. Application de la DoR | User Story clarifiée, critères d'acceptation rédigés (paiement, durée, annulation), maquette Figma validée, dépendance Apple Pay identifiée, estimation 5 SP. |
| 3. Sprint Planning | PBI sélectionné, contribue au Sprint Goal « activer la réservation mobile end-to-end ». Sprint Backlog enrichi. |
| 4. Développement | Pair programming, intégration paiement, tests unitaires + tests d'intégration, code review. |
| 5. Passage à Done | PBI conforme à la DoD : tests E2E verts, accessibilité validée, telemetry en place, déployé en production. |
| Impact | Sprint Goal atteint à 100 %, 0 retour en cours de Sprint, satisfaction PO élevée. |
Definition of Ready vs Definition of Done
| Critère | Definition of Ready | Definition of Done |
|---|---|---|
| Moment d'application | Avant le Sprint | À la sortie du Sprint |
| Objet | Un PBI | L'Increment |
| Statut Scrum | Optionnelle | Engagement officiel (Scrum Guide 2020) |
| Définie par | La Scrum Team (si utilisée) | La Scrum Team, conforme aux standards |
| But | Sécuriser l'entrée dans le Sprint | Garantir la qualité de l'Increment |
| Conséquence si non remplie | Retour en refinement (recommandation) | Le travail ne peut pas être considéré comme livré |
| Présence dans le Scrum Guide | Non | Oui |
Ready vs Done
| État | Ready | Done |
|---|---|---|
| Position dans le flux | Avant le développement | Après le développement |
| Critère | PBI suffisamment préparé | Increment conforme à la DoD |
| Responsabilité | Scrum Team (si DoR utilisée) | Scrum Team (DoD obligatoire) |
| Vérification | Refinement, Planning | Sprint Review, livraison |
| Lien avec Scrum Guide | Non obligatoire | Engagement officiel |
Position Scrum.org et Scrum Guide 2020
Scrum.org reconnaît la Definition of Ready comme une pratique utile dans certains contextes, mais rappelle systématiquement qu'elle n'est pas un élément du framework. Les certifications PSM I, PSM II et PSPO posent régulièrement des questions visant à vérifier que le candidat connaît cette distinction.
Le Scrum Guide 2020 n'utilise jamais le terme « Definition of Ready ». Il évoque uniquement :
- le Product Backlog Refinement comme activité continue ;
- la Definition of Done comme engagement de l'Increment ;
- le Sprint Goal comme engagement du Sprint Backlog ;
- le Product Goal comme engagement du Product Backlog.
15 questions PSM I sur la Definition of Ready
Vous trouverez ci-dessous 15 questions originales dans le style Scrum.org, avec une correction détaillée. Ces questions n'ont pas été copiées de l'examen officiel.
FAQ — questions fréquentes
Retrouvez plus bas, dans la section FAQ structurée, les réponses aux dix questions les plus posées sur la Definition of Ready.
À lire aussi
Source officielle : Scrum Guide 2020.