"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
- des sprint plannings plus courts,
- des séances d'affinages plus fluides
- un travail de rédaction des user stories simplifié
- des estimations plus fiables
- un repère pour toute l’équipe
Exemple de première version de DOR
Une user story prête, c'est une user story qui contient :
- Un titre explicite avec un verbe d’action
- Une description du type « En tant que, je veux, afin de…»
- Une estimation selon la suite de Fibonnacci
- Un test d’acceptation sous la forme étant donné que… quand… alors…
Exemple de version affinée de DOR
Une user story prête, c'est une user story qui contient :
- Un titre explicite avec un verbe d’action
- Une description du type « En tant que, je veux, afin de…»
- Au moins deux tests d’acceptation écrit sous la forme « étant donné que… quand… alors"
- Une valeur métier ou business value
- Une estimation inférieure à 13 selon le référentiel de user stories de l'équipe
et qui peut être
- implémentée en moins de 3j
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 :
- Un libellé de l’US autoporteur idéalement une phrase avec un verbe d'action
- Une description sous la forme :
- En tant que (rôle, utilisateur) ….
- Je veux (besoin, action) ….
- Afin de (valeur métier) ….
- Une valeur métier ou "business value" selon un référentiel posé
- Au moins deux scénarios de tests :
- écrits sous la forme gherkins "étant donnée que...", "quand...", "alors..."
- permettant de valider ou non les règles de gestion associées à l'US
- et que l'on peut utiliser en démo de fin de sprint
- Une étiquette ou un composant "affiné" dans Jira indiquant le passage par l'affinage auprès de l'équipe entière
- Une complexité strictement inférieure à 13 selon le référentiel d'US du socle Valo (US référentes quotées à 3, 5 et 8)
3 Conseils pour finir
