Qu’est-ce que la definition of ready ? Principes et définition

9 février 2024 - minutes de lecture

9 février 2024

Interrogez n'importe quelle équipe agile et vous verrez que le problème n°1 qui revient systématiquement est la qualité des user stories. C'est précisément à ça que sert la definition of ready (DoR).

Dans cet article, je vous explique ce qu'est la definition of ready, pourquoi c'est important, les pièges à éviter et comment vous devez la définir.

Qu'est-ce que la definition of ready ?

La definition of ready, ou DoR, est une liste d'éléments qui définissent la qualité attendue par l'équipe afin de commencer le développement d'une user story dans les projets agiles. Cette liste prend généralement la forme d'une checklist à valider.

Tout comme la definition of done (DoD), la definition of ready contribue à maintenir un haut standard de qualité durant le projet. Elle permet également la facilitation de la communication entre l'équipe de développement et le product owner.

Elle assure également une compréhension commune de ce que signifie une user story prête à être développée, et une user story de qualité.

C'est un levier pour améliorer la qualité de vos user stories. Elle est ainsi complémentaire à la definition of done, qui permet d'assurer un haut niveau de qualité des incréments (le travail livré à la fin du sprint).

Mais contrairement à celle-ci, la definition of ready ne peut s'appliquer que sur les élements

On peut la rapprocher de l'acronyme INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable), qui permet également d'avoir des user stories bien définies.

Comme le dit si bien l'adage : "Garbage in, garbage out".

On ne peut avoir un produit de qualité en sortie du projet que si les entrées (les user stories), sont également de qualité.

Que dit le Scrum Guide sur la definition of ready ?

Le Scrum Guide ne parle jamais de definition of ready : cette notion ne figure tout simplement pas dedans. Pourtant, comme l'explique Barry Overeem dans cet article, il existe une autre notion qui s'y apparente beaucoup : le backlog refinement.

Le backlog refinement permet justement d'estimer, de détailler, d'affiner et de prioriser les éléments du backlog : les user stories.

Barry Overeem explique également les discussions qui ont eu lieu afin de savoir s'ils devaient inclure ou non la notion de definition of ready dans la dernière version du Scrum Guide, et pourquoi cela n'a pas été fait.

Bien que la definition of ready ne soit pas un artefact officiel dans Scrum, cette notion est souvent utilisée par les équipes Scrum.

Quelle est l'origine de la definition of ready ?

Mais d'où vient-elle ? Quelle est l'origine de la definition of ready si ça ne provient pas du guide Scrum ?

Et bien, plusieurs grands noms de l'agilité en ont parlé sur leurs blogs ou chaînes Youtube, dont Jeff Sutherland, le co-créateur de Scrum (rien que ça !).

Je vous laisse la vidéo pour les plus curieux.

Avantages de la definition of ready

"Oui bonjour, vous pourriez me rajouter un bouton sur ma page web svp, qui pointe vers la page produit ?"

"Sans problème, ce sera fait au prochain sprint".

Le même client, lors de la sprint review :

"Mais c'est quoi ça ? C'est pas du tout ce que je vous ai demandé. Cette couleur est horrible, et puis le placement du bouton ça va pas dut out. Et le texte, n'en parlons même pas. Faut tout revoir..."

Cette situation vous parle ? C'est justement ce que la definition of ready permet d'éviter, en ayant un besoin plus précis et mieux exprimé avant de se lancer dans le développement.

Petit tour des avantages qu'apportent la definition of ready :

  • Assurer la compréhension de ce que signifie être prêt.
    Avoir une compréhension mutuelle de ce qu'est une bonne user story permet d'éviter les problèmes classiques de communication, mais aussi d'éviter de travailler inutilement.
  • Maintenir un haut niveau de qualité.
    En injectant des user stories de qualité dans le sprint planning, l'équipe de développement peut fournir un travail de meilleure qualité, et maximiser la valeur apportée au client et aux utilisateurs.
  • Contribuer à la transparence et la confiance entre l'équipe de développement et le product owner.
    Fini les échanges tendus entre l'équipe de développement et le product owner, où chacun se renvoie la balle et accuse l'autre de mal faire son job. En se mettant mutuellement d'accord sur la definition of ready, cela clos les débats.
  • Apporter des bonnes pratiques dans l'équipe.
    La definition of ready permet d'apporter des bonnes pratiques dans la rédaction et la spécification des récits utilisateurs, ce qui contribue à davantage de qualité.
  • Agit comme garde-fou pour éviter les spécifications à rallonge ou sans intérêts.
    Elle permet également de détecter les user stories trop volumineuses, vides de sens ou pas assez explicites, avant qu'il ne soit trop tard.

Definition of ready vs Definition of done : quelles différences ?

La definition of ready permet d'améliorer la qualité des user stories afin de pouvoir les développer. La definition of done permet de s'assurer qu'un travail terminé est bien fini à 100%, selon les critères définis.

Voici une image qui permet de mieux comprendre où agissent les definition of ready et definition of done :

definition of ready vs definition of done

Le développement est borné entre la definition of ready et la definition of done

Qui est responsable de la definition of ready ?

La definition of ready doit être définie par le Product Owner ainsi que l'équipe de développement, d'un commun accord. Elle doit être la plus légère possible, et évoluera au fur et à mesure des itérations et des besoins.

Je recommande de planifier un atelier de 30 minutes à 1 heure maximum afin de définir ensemble ce qu'est une user story de qualité. Donc de décider du contenu de la definition of ready.

Vous pouvez même vous servir de la première rétrospective pour cela, en vous appuyant sur l'apprentissage du premier sprint.

Exemples de definition of ready

La definition of ready est un levier pour améliorer la qualité de vos récits utilisateurs. Pour cela, elle prend généralement la forme d'une checklist.

Voici quelques exemples d'éléments que l'on peut retrouver dans une definition of ready :

  • Un titre explicite.
  • Une description ou une proposition de valeur, la plupart du temps formulée comme ceci : "En tant que [..], je peux [...] afin de [...]."
  • Une hypothèse, formulée comme ceci : "Nous croyons que [...]. Nous aurions raison si [...]. Ce qu'on a fait [...].
  • Une estimation, réalisée lors du planning poker.
  • Les critères d'acceptation, ainsi que les tests à réaliser pour valider le travail sur cette user story.
  • Les dépendances. Idéalement, il ne devrait pas y en avoir, mais on sait tous qu'entre la théorie et la pratique il y a un monde)
  • Un jeu de données de tests fourni à l'équipe.
  • Une maquette.
  • Une liste des performances attendues
  • etc...

La definition of ready peut-elle évoluer en cours de projet ?

La definition of ready peut et doit évoluer en cours de projet, au fur et à mesure des itérations et de l'apprentissage de l'équipe. La rétrospective est le moment parfait pour améliorer la definition of ready, afin d'intégrer des critères de plus en plus stricts.

Attention cependant. La definition of ready ne doit pas être revu unilatéralement par l'équipe de développement pour renvoyer le product owner dans les brancards, ou inversement.

Il s'agit d'un travail commun, qui doit être réalisé en partenariat entre l'équipe de développement et le product owner.

Toutes les user stories doivent-elles être ready avant de démarrer un sprint ?

Il n'est pas nécessaire que toutes les user stories doivent être en ready pour réaliser le sprint planning ou commencer le sprint.

Ne tombez pas dans ce piège !

Vous devez voir la definition of ready comme une guideline, une aide, un repère pour mieux définir vos user stories. Pas comme quelque chose de strict qui doit absolument être respecté avant de passer les user stories en "To Do".

En pratiquant ainsi, vous perdrez en agilité et vous reproduirez le schéma des méthodologies de gestion de projet prédictives traditionnelles.

Gardez à l'esprit qu'une user story peut être affinée au dernier moment, même si elle a un haut niveau de priorité. Cela peut notamment se faire via un atelier de 15 minutes pour peaufinier ensemble les critères d'acceptation, entre l'équipe de développement et le product owner.

Il est aussi possible d'ajouter des items au sprint backlog qui ne sont pas détaillés lors du sprint planning, ou même pendant le sprint en court.

Il conviendra alors de les détailler dès que possible pour la réussite de l'objectif de sprint.

Comment choisir la definition of ready ?

Organisez un atelier de 30 minutes à 1 heure en invitant les membres de l'équipe de développement et le product owner, afin de récolter les besoins et de rédiger une première version (la v1) de la definition of ready.

Voici les questions-clés auxquelles cous devrez répondre :

  • Quel est le format d'user stories que l'on a utilisé jusqu'ici ?
  • Qu'est-ce qui marche ?
  • Qu'est-ce qui manque ?
  • Comprenez-vous ce format de user stories ?
  • Y a t-il une amélioration par rapport aux précédentes user stories ?
  • De quelles informations manquantes avez-vous besoin ?

Assurez-vous tout de même de ne pas rédiger quelque chose qui ne peut pas être tenu.

Il vaut mieux partir sur une definition of ready light mais imparfaite quitte à l'améliorer ensuite, plutôt que sur quelque chose d'hyper complet, mais d'inatteignable.

Vous pouvez également utiliser le kit DoR Kards, qui a été construit afin de vous assister à la mise en place d'une definition of ready. 

Vous pouvez le télécharger et l'imprimer en cliquant sur ce lien.

Les pièges à éviter avec la definition of ready

Voici 5 pièges dans lesquels vous devez éviter de tomber avec la definition of ready :

  1. Ne pas faire ce qui est marqué dans la definition of ready.
    Si c'est écrit dans la definition of ready, il faut s'y conformer. Si ce n'est plus nécessaire, alors c'est le moment de revoir la definition of ready.
  2. Être trop procédurier et trop exhaustif.
    L'objectif de l'agilité est la collaboration entre tous les membres d el'équipe agile et les parties prenantes. Une definition of ready n'est pas fait pour que l'équipe de développement fasse front au Product Owner.
  3. Considérer que toutes les users stories doivent être ready avant le début du sprint.
    En procédant ainsi, vous perdez en agilité, et vous reproduisez ce que propose les méthodologies prédictives, à savoir : tout prévoir, tout estimer, tout planifier avant de commencer à travailler.
  4. Spécifier toutes les user stories en sprint planning.
    La definition of ready indique ce que doit être une user story prête à être développée. Mais ce travail peut être mené en corus de sprint. Pas nécessairement au début ou lors du sprint planning.
  5. Rédiger une definition of ready sans concertation interne.
    La defintion of ready est définie via un travail commun entre l'équipe de développement et le product owner. Quand je parle de travail commun, ce n'est pas "je décide de mon côté, et j'en informe l'autre". C'est vraiment une collaboration.

La definition of ready est-elle anti-agile ?

Certains agilistes voient la definition of ready comme une contrainte, et comme quelque chose d'anti-agile hérité des méthodologies de gestion de projet traditionnelles.

C'est vrai qu'elle est souvent mal utilisée, notamment dans les équipes qui considèrent que les user stories doivent être en statut "ready" afin de passer dans la colonne "Todo" du sprint backlog.

Appliqué comme ça, c'est une grosse perte d'agilité.

Mais bien utilisé, la definition of ready peut apporter beaucoup de bonnes choses, et notamment de la qualité et une communication apaisée.

Alors, la definition of ready est-elle vraiment anti-agile ? Je réponds à la question dans cet article.

Je vous laisse avec cette vidéo de Judicael Paquet qui nous donne son avis sur la question.


Thibault Baheux

Tour à tour chef de projet puis manager d'équipe depuis 2008, je suis aujourd'hui directeur de projet indépendant.

J'ai décidé via ce site de démocratiser la gestion de projets et de la rendre accessible à tous.

Mes certifications : Prince2 Foundation, CompTIA Project+ certified, PSM1, PSPO1, Lean Six Sigma Black Belt.


Articles Similaires


{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Transformez votre prochain projet en succès !