"les US avaient juste un titre qui n'était pas forcément explicite".
"Le PO n'a pas le temps de bien les écrire". "Il ne sait pas forcément comment les écrire avec des cas de tests réels". "Ça prend du temps d'écrire des cas de tests."...
D’où l’importance de mener un atelier sur la définition du “prêt au développement” ou Definition of Ready (DOR) d’une US. Et une fois la première version de la DOR posée, ça vaut le coup de la relire régulièrement pour l'améliorer, la compléter, et cela en suivant une approche itérative.
Déroulé de l'atelier
Je commence par soulever la question au groupe. Les éléments remontés portent souvent sur des éléments présents dans la DOR déjà existantes ou des éléments génériques du type "elle doit avoir des cas de tests", "elle doit être claire pour les developpeurs".
C'est une opportunité pour moi d'introduire l'importance d'avoir des points factuels, précis dans une définition of ready, des points que l'on peut checker à "pass" ou "unpass".
Je prends leurs exemples. Si vous me dites que l'US doit avoir des cas de tests, comment je sais si elle est prête à être développée ? "Des cas de tests" : combien ? 2, 8;,12 ?
"elle doit être claire pour les développeurs" : quel élément factuel me permet de savoir si elle est claire pour les développeurs ? Que signifie "claire" dans ce contexte ?
J'en profite ensuite pour proposer une définition et j'invite le groupe à la compléter, la modifier.
La Definition Of Ready (DOR) est la liste d’éléments attendus, qu’une user story doit rassembler pour être proposée au développement.
Cette liste est définie par l'équipe ou par un ensemble d'équipes appartenant à un même train Safe pour les projets en agile à l'échelle par exemple.
Et j'en profite pour rappeller en parallèle ce qu'est une définition de finie ou "done" :
La ou les Definitions Of Done (DOD) définissent la liste des conditions nécessaires pour qu’une user story puisse passer d’un état à un autre (ou d’une colonne à une autre de votre tableau Kanban).
Le travail de développement d’une user story pourra débuter si et seulement si la DOR est conforme.
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 user story d’une colonne à l’autre.
La DOR : un outil ou une contrainte ?
La Definition Of Ready est avant tout un outil, une aide, un repère. Je recommande de mettre une DOR sur vos projets. Restez minimaliste au début, la complexification émergera ensuite au fur et à mesure des itérations de l'équipe.
La DOR répond au besoin de l’équipe de connaître les pré-requis d’une user story pour sa phase de développement.
La user story "ready" est le fruit d'échanges entre le PO et les devs. Les US sont présentées le plus tôt possible pour être challengées par les développeurs sur leur découpage, et leur affinage.
La DOR ne doit pas être une contrainte mais plutôt un outil de collaboration entre PO et devs. C'est également un outil d'obtention de consensus facilité dans le cadre des sprints planning meeting ou des séances d'affinages.
La Definition Of Ready doit rester pour tout le monde une liste de points de repères. Elle doit vous aider à vous poser les bonnes questions au moment de le rédaction de vos user stories ainsi que lors des moments d'affinages des user stories. C’est une aide à la relecture, à la prise de recul pendant les phases de rédaction et d'affinage.
Les bénéfices directs
Exemple de première version de DOR
Une user story prête, c'est une user story qui contient :
Exemple de version affinée de DOR
Une user story prête, c'est une user story qui contient :
et qui peut être
Un exemple de DOR validée avec une équipe projet
Définition de "Ready" ou DOR
Une user story prête, c'est une user story qui contient :
3 Conseils pour finir
Vous y êtes presque...
Nous venons de vous envoyer un e-mail. Veuillez cliquer sur le lien contenu dans l'e-mail pour confirmer votre abonnement !