Explorer la Definition Of Ready (DOR)

La Definition Of Ready correspond à l’état attendu de la demande en entrée de responsabilité de l’équipe agile. Issue des pratiques SCRUM, la DOR correspond généralement à un accord passé entre l’équipe de développement et le PO. Si elle est respectée, l’équipe peut s’engager sur l’US en question. Si elle en l’est pas, alors l’équipe a le droit de refuser d’intégrer la User Story dans le Sprint qui va démarrer.

Mais à quoi correspond réellement la Definition Or Ready ? La DOR doit contenir la liste des éléments communs à toutes les US qui doivent être disponible au lancement du Sprint afin que l’équipe sache ce qui est attendu de la solution apportée au besoin exposé par l’US. On considère généralement que la DOR doit au moins correspondre à l’INVEST (Topic Card 154). La DOR peut donc contenir à la fois des éléments de description du besoin et de sa réponse (spécifications) mais aussi des éléments spécifiques au test du développement, des maquettes… tout ce qui correspond à ce dont l’équipe a besoin.

Il est important de comprendre que la DOR n’est pas une définition gravée dans le marbre, elle peut évoluer au fur et à mesure de la vie de l’équipe et du produit. En effet, tenter de produire une DOR ultra complète au lancement d’une équipe est illusoire. Si on tente l’exercice, l’équipe se rendra rapidement compte que la DOR produite n’est jamais atteignable et qu’ils finissent par l’ignorer. Il vaut mieux être ultra réaliste dans la création de la DOR, afin qu’elle ne contienne que des choses atteignables maintenant (et nécessaires maintenant). Imaginer avoir, dés le lancement d’un produit, des données complètes de recette, par exemple, est souvent difficile. L’équipe peut cependant créer une version actuelle de la DOR ainsi que la projection de leur prochaine version de celle-ci. De fait, dans son amélioration continue, elle pourra alors aborder régulièrement cette version projetée et mettre en place les actions d’amélioration continue qui lui permettront de se rapprocher de cette définition.

De plus, au fur et à mesure de la vie de l’équipe et de sa prise d’autonomie sur la création de son produit, on verra souvent les équipes ne plus nécessiter certaines informations. Par exemple, au lancement d’un produit les maquettes seront généralement un élément central de la DOR afin que l’équipe sache comment le produit est envisagé. Avec les itérations qui passent, l’équipe sera de plus en plus familière avec le design de l’application, jusqu’à ne plus avoir besoin de ces maquettes. Il sera alors temps pour elle de revoir sa DOR afin de s’assurer que seuls les éléments primordiaux y sont inscrits.

Nous recommandons souvent de créer un atelier avec l’équipe afin de créer cette première version de la DOR. Ce dernier sera également réutilisable lors de certaines rétrospectives qu’on orientera sur cette définition. Pour cela, un format a été créé spécialement : les DOR/DOD Kards.