QU’EST-CE QU’UNE US “Ready To Dev”?

J’ai rejoint un projet. Les douleurs que me rapportaient les membres de l’équipe concernaient la qualité des userstories (US). Elles ne comportaient qu’un titre, pas forcément explicite. Le product owner (PO) s’était habitué au fonctionnement suivant : “tu as une question sur une US, bah viens me voir, je suis dispo !” :) Le pattern pourrait fonctionner, et encore, pas dans ces conditions. Et à distance...

Nous avons donc mené un atelier sur la définition du “prêt au développement” ou Definition of Ready (DOR) d’une US. Pour cela, toute l’équipe s‘est réunie, pour donner sa vision d’une US parfaite. L’atelier était sous la forme d’une rétrospective KEEP/DROP/START (KDS)__.

En 1 heure, nous avions une vision cohérente et commune d’une user story de qualité. Elle a été affichée au mur, avec les autres éléments de management visuel de l’équipe et l’équipe s’y réfère lors des backlog grooming et des sprint plannings.

Qu’est-ce que la definition of ready ?

Au minimum, la Definition Of Ready (DOR) répond aux questions suivantes :

Why ? What ? How ? How Many ? What size ?

Je préfère retenir la définition suivante élaborée sur la base de mes expériences :

La Definition Of Ready (DOR) est la liste (définie par l’équipe) d’éléments attendus qu’une user story doit rassembler pour être candidate au développement.

Pour faire plus simple, je vais prendre le parallèle avec les Definitions Of Done (DOD). Elles définissent la liste des conditions nécessaires pour qu’une userstory puisse passer d’un état à un autre (ou d’une colonne à une autre de votre board). Le travail de développement d’une user story pourra débuter si et seulement si la DOR est conforme. Elle fait le pont entre le board “Rédaction des US” et le board “Développement”.

Au passage, on souligne que le développement d’une userstory est bornée entre sa DOR et sa DOD.

Exemple de board visuel - En rouge la DOD (à droite) et la DOR (à gauche). En violet, les DOD partielles qui définissent le passage d’une usertory d’une colonne à l’autre.

Constituer la liste des éléments attendus est un déclencheur pour mener une réflexion ou une discussion à plusieurs. Elle doit amener un travail collectif en fonction des attendus.

Est-ce un outil ou une contrainte ?

La Definition Of Ready est avant tout un outil, une aide, un repère. Je vous recommande de mettre une DOR sur vos projets. Elle sera au début minimaliste, mais sa complexification émergera de l’équipe au fur et à mesure des itérations. Elle répondra au besoin de l’équipe de connaître les pré-requis d’une userstory pour sa phase de développement.

Je vois dans la mise en place de la Définition Of Ready un levier pour améliorer la qualité des user stories, et ainsi faciliter les phases suivantes de notre système de delivery. Dans certains contextes, elle sera un garde-fou pour éviter que l’US devienne un dépotoire de spécifications à rallonge ou un ensemble vide.

A gauche : exemple d'une DOR minimaliste - A droite : exemple d'une DOR plus aboutie après plusieurs itérations

Pourquoi aurais-je besoin de la DOR ?

Avant tout, et il faut le noter, ce type d’atelier permet à l’équipe de se regrouper autour d’une thématique méthodologique. Elle implique une réflexion de groupe, un investissement de chacun et permet d’aligner les membres de l’équipe sur une vision commune d’une user story type.

Les bénéfices de la Definition of Ready (DOR)

La première utilité est d’éviter des sprint plannings à rallonge qui impactent directement l’efficacité de l’équipe et dans certains cas sa motivation. Si l’US respecte la DOR, alors les développeurs auront tous les éléments pour estimer l’US, sans avoir besoin de poser de multiples questions pour cerner le périmètre de l’US ni risque de sous estimer une US sans avoir pris en compte un aspect technique qui n’était pas repérable.

La deuxième utilité est de simplifier le travail de rédaction pour espérer avoir une user story candidate au développement. C’est un peu la check-list avant le décollage. Elle limite ainsi les risques de re-spécifications, les évolutions ou anomalies et les incompréhensions. Le biais qui en découle est l’augmentation de la qualité des user stories.

La troisième utilité, qui interviendra plutôt à moyen terme, est que les estimations des développeurs vont êtres de plus en plus précises. Elles vont gagner en fiabilité, car le besoin sera sûrement mieux compris, mieux cerné. Par la même, c’est aussi la prédictibilité de l’équipe qui sera améliorée.

La quatrième utilité est de donner des repères à l’équipe. La DOR va permettre de structurer vos US et d’avoir un template commun. Vos développeurs seront alors familiers avec vos stories et sauront facilement se repérer pour récupérer les bonnes informations au bon moment.

Comment mettre en place la DOR ?

Comme pour beaucoup de décisions que prennent les équipes agiles, la DOR doit être élaborée par le biais d’une discussion ouverte où chaque membre de l’équipe partage sa vision d’une user story la plus claire possible. La diversité des rôles et des fonctions permet d’avoir une définition la plus compréhensible possible, et une équipe alignée sur cette définition. Chaque interlocuteur voit une US selon son prisme de compétence ou selon son expérience. C’est bien cette diversité des points de vue qui permet une meilleure convergence pour une US parfaite. La DOR n’est pas figée dans le temps. Elle est amenée à évoluer, en parallèle de la progression de l’équipe dans la confiance qu’elle se donne et dans la maturité qu’elle acquiert. Sans la changer à chaque fin de sprint, l’équipe prendra le temps nécessaire pour mettre à jour la DOR en fonction du contexte (ie. tous les deux sprints au début, puis tous les 6 sprints).

Sur notre projet, nous devions développer un lot d’API et une interface web. C’était deux produits à faire évoluer en parallèle. Dans ce cas, nous n’avons pas réussi à converger vers une seule DOR. En effet, en fonction de notre découpage, nous avons été amenés à avoir des stories back, d’autres plus front. Dans ce cas, le plus simple est d’avoir plusieurs DOR : une DOR par grand type d’US (ie. une US de type API, une US de type Front, bugs). On a gagné en clarté, en simplicité et en adaptabilité.

Ce qu’il faut retenir

L'US ready est le fruit de la discussion amont entre le PO et les devs. Les US sont présentées en amont pour être challengées par les devs sur le découpage, l'expression du why, la proposition de valeur, etc.

La DOR ne sera pas une contrainte si elle est élaborée par l’équipe pour répondre à une douleur. Elle sera plutôt bien accueillie et permettra aussi de protéger l’équipe technique lors des phases d’estimation et de développement. A l’inverse, si ce n’est pas utile, on ne cherchera pas à l’imposer.

La Definition Of Ready doit rester pour tout le monde des lignes de conduite, des principes. Elle vous aidera à vous poser les bonnes questions au moment de rédiger une US. C’est une aide à la relecture, à la prise de recul pendant cette phase de rédaction.

En terme de bénéfice, on s’attend à avoir des sprint plannings plus courts, un travail de rédaction des US simplifié, des estimations de plus en plus fiables avec le temps et un repère de plus pour l’équipe.

La DOR ne vous empêche pas de mettre en place des ateliers de co-construction type “3 amis”, “example mapping”, etc.