La Definition of Ready (dor)

definition of ready
definition of ready

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.

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 :

Definition of Ready
Definition of Ready

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.

[ Article lu 15 fois aujourd'hui ]
A propos Judicaël Paquet 526 Articles
  Paquet Judicaël (coach agile et devops sénior) Mes activités en France et en Suisse : - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile. [Suisse/France]

Soyez le premier à commenter

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.