Definition of Ready : l'outil qui réduit les bugs en sprint
Definition of Ready : l'outil qui réduit les bugs en sprint
Il y a quelques années, j'accompagnais une équipe de développement dans le secteur des médias. Chaque sprint, des stories revenaient en fin de revue avec le même commentaire du PO : "Ce n'est pas ce que j'avais demandé." Les développeurs étaient frustrés. Le PO était frustré. Et pourtant, chacun avait l'impression d'avoir bien fait son travail.
J'ai analysé les stories des trois derniers sprints. Aucune n'avait de critères d'acceptation écrits. Aucune. Les développeurs avaient interprété les spécifications. Le PO avait imaginé quelque chose d'autre. Le bug n'était pas dans le code : il était dans la story.
Ce pattern, je l'ai vu dans toutes les organisations où j'ai travaillé : BNP Paribas, Canal+, Agirc-Arrco. Les bugs de sprint viennent rarement d'un code mal écrit. Ils viennent d'une spécification que tout le monde pensait comprendre, et que chacun avait interprétée différemment.
La Definition of Ready est le filtre qui arrête ces bugs avant qu'ils coûtent.
Ce que la DoR résout vraiment
Dans les équipes que j'accompagne, 60 à 70% des bugs de sprint trouvent leur origine dans une story mal définie. Pas dans un développeur incompétent. Pas dans une architecture fragile. Dans l'ambiguïté d'une spécification.
La DoR (Definition of Ready) est le contrat d'entrée en sprint. Elle pose une question simple : "Cette story est-elle suffisamment claire pour que l'équipe puisse la développer sans devoir s'arrêter pour poser des questions ?"
Une story non-prête qui entre en sprint génère en moyenne 3 interruptions pour des clarifications (chacune coûtant 30 minutes de contexte-switching au développeur et 15 minutes au PO). À cela s'ajoute une probabilité de 40% que la story ne soit pas acceptée en fin de sprint, nécessitant un sprint supplémentaire. Coût total : 2 à 5 fois le coût d'une story bien préparée.
Le calcul est simple. Les critères d'acceptation écrits en affinage prennent 15 minutes. Les aller-retours en cours de sprint coûtent 9 heures. La DoR n'est pas de la bureaucratie : c'est de l'économie.
Les 5 critères de la DoR
Une DoR n'est pas universelle : elle doit refléter les problèmes spécifiques de votre équipe. Mais 5 critères sont quasi-universels, et je commence toujours par ceux-là dans les ateliers que j'anime.
Critère 1 : L'objectif business est clair. "Pourquoi livrons-nous cette story ? Quel problème utilisateur résout-elle ?" Une story sans objectif business génère des décisions de design arbitraires : les développeurs inventent la valeur qu'ils n'ont pas reçue.
Critère 2 : Les critères d'acceptation sont écrits. Au moins 3 scénarios Gherkin (Given/When/Then) ou une liste de conditions vérifiables. "L'utilisateur peut se connecter" n'est pas un critère d'acceptation. "Étant donné un utilisateur avec un email valide et un mot de passe correct, quand il soumet le formulaire, alors il est redirigé vers le dashboard" en est un.
Critère 3 : Les dépendances sont identifiées. La story dépend-elle d'une API externe, d'un autre sprint, d'une décision non-prise ? Si oui, ces dépendances sont documentées et leur statut est connu. Une dépendance découverte en sprint crée un blocage non planifié.
Critère 4 : La story est estimable. L'équipe peut donner un ordre de grandeur après avoir lu la story. Si elle ne peut pas estimer, c'est qu'il manque de l'information, pas que l'équipe est incompétente.
Critère 5 : La story est indépendante et livrable. Elle peut être développée sans bloquer sur une autre story du même sprint, et elle produit de la valeur de façon autonome. Les stories qui s'enchaînent sans être livrables séparément créent des cascades de blocages.
Ces 5 critères s'affichent dans l'espace de travail de l'équipe et s'intègrent dans le template de story Jira ou Linear. Deux heures en atelier suffisent pour les définir collectivement.
Vos sprints finissent avec des stories incomplètes parce que les specs manquaient de clarté ?
La DoR seule ne suffit pas si le processus d'affinage est absent ou dysfonctionnel. En 30 minutes, j'identifie les failles de votre processus de préparation du backlog et vous donne un plan de correction concret, celui qui réduira vos bugs de sprint de 50% en 2 mois.
Le rituel de validation avant le sprint planning
Deux jours avant chaque sprint planning, le Scrum Master et le PO passent en revue les stories candidates et vérifient chaque critère de la DoR.
Le résultat est binaire :
- Story prête : tous les critères sont satisfaits → elle peut entrer en sprint planning
- Story non-prête : au moins un critère manque → elle est exclue avec une note expliquant ce qui manque
Cette étape prend 30 minutes maximum. Elle évite des heures de discussion pendant le sprint planning sur des stories qui ne sont pas prêtes. Quand j'ai introduit ce rituel dans une équipe Agirc-Arrco, le sprint planning est passé de 3h30 à 1h45 en deux sprints.
Le résultat de cette validation est une liste de stories "DoR-validées" qui entre au sprint planning, et une liste de stories "DoR-en-attente" avec les actions nécessaires pour les préparer au sprint suivant.
Gérer la pression de "remplir le sprint malgré tout"
La résistance principale à la DoR est prévisible : "On ne peut pas laisser le sprint vide parce que quelques stories ne sont pas prêtes."
Cette pression est compréhensible. Elle est aussi exactement ce qui crée les bugs. "On verra en cours de sprint" : c'est le moment où l'ambiguïté devient un bug de production.
Si le sprint n'a pas assez de stories "DoR-validées" pour remplir la capacité de l'équipe, deux options valables :
- Utiliser la capacité pour des stories techniques (refactoring, réduction de dette technique) qui n'ont pas besoin de spécification fonctionnelle (elles se trouvent dans un backlog craft bien entretenu)
- Réduire le périmètre du sprint plutôt que d'accepter des stories non-prêtes
Un accord d'équipe sur cette règle doit être établi dès l'introduction de la DoR, idéalement en rétro, avec le soutien du Tech Lead et du PO.
Les métriques qui mesurent l'impact
Deux métriques permettent de mesurer l'impact de la DoR sur la durée.
Taux de stories refusées au sprint planning : nombre de stories exclues parce qu'elles ne passaient pas la DoR, divisé par le nombre total de stories candidates. Objectif : descendre à moins de 10% après 3 mois. Un taux élevé révèle un problème en amont dans le processus d'affinage, pas dans la DoR elle-même.
Taux d'acceptation des stories en fin de sprint : nombre de stories acceptées par le PO, divisé par le nombre de stories engagées. Objectif : dépasser 90%. Ce taux augmente significativement dans les 6 à 8 premières semaines après introduction de la DoR quand le processus est bien suivi.
FAQ sur la Definition of Ready
1. Quelle est la différence entre la DoR et la Definition of Done ?
La DoR est un critère d'entrée en sprint : elle définit ce qu'une story doit contenir pour être développable. La DoD est un critère de sortie de sprint : elle définit ce que le code doit respecter pour être considéré terminé. Les deux sont nécessaires et complémentaires. Une DoR sans DoD produit des stories bien spécifiées mais mal développées. Une DoD sans DoR produit du bon code sur de mauvaises spécifications.
2. La DoR s'applique-t-elle aussi aux stories techniques (refactoring, infrastructure) ?
Oui, avec des critères adaptés. Pour une story technique, les critères d'acceptation sont remplacés par des critères de succès mesurables : "la couverture de tests du module X passe de 30% à 60%", "le build time est réduit de 8 min à 4 min". L'objectif business est remplacé par l'impact technique quantifié. L'importance de la DoR est la même : une story technique ambiguë produit du travail mal orienté.
3. Que faire si le PO résiste à rédiger des critères d'acceptation détaillés ?
Montrer le coût avec un exemple concret du sprint précédent. "Cette story a nécessité 3 aller-retours avec toi en cours de sprint parce que le comportement attendu n'était pas spécifié. Chaque aller-retour a coûté 2h au développeur et 1h à toi. Rédiger des critères d'acceptation en affinage prend 15 minutes, et évite 9 heures de friction." Le chiffre parle mieux que l'argument de principe.
4. Comment combiner DoR et agilité dans un contexte de startup avec des requirements qui changent vite ?
La DoR n'est pas incompatible avec l'agilité rapide : elle est compatible avec une agilité mature. Une startup en phase de discovery peut avoir une DoR allégée : le critère 2 est "au moins 1 scénario défini" au lieu de 3. L'essentiel est que l'équipe ne parte pas développer sans une compréhension partagée du "quoi" et du "pourquoi". Le reste peut rester flexible.
5. Quelle est la taille idéale d'une DoR ?
Commencer avec 5 critères. Observer l'impact pendant 2 mois, puis ajouter des critères si des problèmes spécifiques persistent. J'ai vu des équipes créer des DoR de 15 critères qui rendaient chaque story impossible à préparer en moins de 2 heures. Une DoR trop longue devient une barrière bureaucratique, l'inverse du but recherché.
Ressource gratuite : Guide Lead Time -50% en 90 jours
Le framework complet pour réduire votre lead time de moitié en 90 jours, incluant une section dédiée à l'optimisation du processus d'affinage et à l'implémentation de la Definition of Ready avec les templates prêts à l'emploi.
