La pratique de la Definition of Ready est tout aussi populaire que la Definition of Done… Bien que la pratique est intéressante, il faut la manipuler avec une grande précaution.
Vous pouvez regarder la vidéo de La Minute Agile qui traite de ce sujet :
La definition of Ready
La definition of Ready représente l’ensemble des critères qui définissent ce qu’est une user-story (ou autres items) prêt à être développé. Nous l’appelons souvent « Dor » dans les équipes scrum.
Scrumbut à éviter sur la Definition of Ready
Attention de ne pas faire cette erreur classique : quand nous parlons de « ready », nous ne parlons pas de « todo ». Le « todo » est la colonne généralement utilisée pour positionner tous les items que nous désirons réaliser pendant le sprint. Cependant, il n’est pas interdit de rajouter des items qui ne sont pas « ready » dans le « todo » de notre sprint ; tous les items en « todo » n’ont aucune obligation d’être terminé au moment où l’équipe les choisi.
Vous pouvez éventuellement rajouter une colonne ready si l’équipe scrum en a besoin pour une meilleure visibilité comme ceci :
Voici un petit rafraichissement du Scrum Guide dans sa définition de la sprint planning, qui rappelle que les éléments sélectionnés lors de cette cérémonie ne sont pas forcément « ready ».
Le Product Owner discute de l’objectif que le Sprint devrait concrétiser et des éléments du Backlog produit qui, s’ils sont complétés durant le Sprint, pourraient permettre d’atteindre l’objectif du Sprint.
scrum guide
Comment définir sa Definition of Ready ?
Nous allons proposer aux développeurs de donner leurs exigences sur la définition d’une user-story « READY ». Le product owner est consultant car il peut proposer de très bonnes idées.
Voici quelques idées de ce que nous pouvons retrouver régulièrement :
La user-story doit être INVEST
user-story « Indépendante », « Négociable », « Valeur business », « Estimable », « Suffisamment petite » et « Testable ».
J’en parle de façon plus précise dans cet article : Comment découper ses user-story ?
Pour ma part, j’estime que par défaut toutes les user-stories devraient être INVEST pour des raisons de qualité. Cependant, il est important que les développeurs soient d’accord avec cette idée (voire le product owner).
Mettre des tests d’acceptance
Quels sont les tests à réaliser qui valideront que la user-story est valide ?
Des user-stories en mode hypothèse and measure
Ces 3 phrases permettent concrètement de travailler dans un mode Lean Startup. Il est très intéressant pour les développeurs de comprendre la base des user-stories que nous allons créer :
"Nous croyons que ... Nous aurons raison si ... Ce qu'on a fait .... "
Il faut par contre bien comprendre que cet ajout prend du temps au product owner car cela implique plus de travail mais le faire permet au product owner de bien partager la vision du projet voire de l’évolution du projet.
Voilà un petit exemple concret :
"Nous croyons que le mobile est devenu indispensable pour vendre des produits Nous aurons raison si 30% de nos clients aimeraient acheter nos produits avec leur mobile Ce qu'on a fait : travailler sur une app mobile pour répondre à la demande "
Nous pourrions créer une « Hypothese and Measure » pour des Epics, des personae, des user-stories unitairement… Ce qui compte, c’est que chaque user-story soit associée à l’une des Hypothese and Measure définit.
Conclusion Definition of Ready
La definition of ready qui n’est pas une exigence scrum est une pratique intéressante pour améliorer l’organisation de l’équipe sur un sprint. Mais attention de ne pas oublier qu’un item peut devenir « ready » en cours de sprint et qu’il n’est en aucun cas obligatoire que tous ces items soient « ready » pour entrer dans le sprint backlog.
Depuis 6 ans maintenant et plus de 800 élèves formés à l’agilité, j’ai eu de nombreuses fois l’occasion de discuter du DOR avec les élèves. Toutes les discussions ont abouti à la conclusion que c’est un cache misère. En effet, soit cela cache un manque de confiance entre la DT et le PO qui amène à contractualiser, soit cela met en avant une complexité de la formalisation des besoins (trop de formalisme, de contenu, etc) qui ne devrait pas exister. Il faut chercher à faire simple pour avoir une meilleure maitrise et il y a peu de cas où ce n’est pas possible. Le mieux restant toujours l’accompagnement du PO auprès de l’équipe plutôt qu’une formalisation officielle et contractuelle.
Il n’est donc jamais arrivé que le DOR soit une pratique justifiée. Peut-être avez-vous un exemple contraire ?
Pour ma part, de mon expérience, elle est souvent mal appliquée. La vidéo d’ailleurs rappelle le « attention » sur cette pratique. Pour ma part je suis pas grand fan. Je pense que la bonne utilisation est dans le sens : « ensemble, quel format de user story nous pouvons utiliser » (Dev team + PO). Et là dans ce cas c’est intéressant mais c’est plus un formalisme.
Mais le soucis de cette pratique c’est que les équipes n’osent plus mettre une US presque vide en sprint planning qui sera maturée en sprint. Donc je suis en général pas fan et je la recommande en aucun cas aux équipes novices.