Faire la Definition of Done des user-story

Ecrit par << Paquet Judicaël >>

En Scrum (voire d’autres méthodes), on aime proposer des user-story complètes afin que le travail au final soit de la meilleure qualité possible. Une user-story n’est pas qu’un simple « story friendly » (En tant que [persona], je souhaite [souhait] afin de [but]). Afin de s’adapter au contexte et de travailler en équipe, les coach agile aiment beaucoup faire un atelier pour définir le « Ready » et le « Done » qui permet de faire le Definition of Done.

Qui va définir le Definition of Done ?

Le coach Agile va réunir l’équipe de développement (ou les équipes dans les framework tels que LeSS ou Nexus) et le Product Owner afin de travailler sur la Definition of Ready et la Definition of Done.

Voilà la demande du Product Owner concrète si on pense Scrum : « En tant que Product Owner, je souhaite avoir une Definition of Ready afin de donner des user-story complètes aux développeurs pour commencer à travailler dessus ».

Voilà la demande des développeurs concrète si on pense Scrum : « En tant que développeur, je souhaite avoir une Definition of Done afin de donner des fonctionnalités complètes et de qualité au Product Owner pour qu’il puisse les tester ».

Definition of Ready

Comment définir une user-story qui est prête à être prise en charge par les développeurs (dans la colonne « TODO ») ?

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.

Les idées qu’on retrouve souvent :

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-story devraient être INVEST pour des raisons de qualité mais il est important que les développeurs soient d’accord avec cette idée (voire le Product Owner).

Mettre des tests d’acceptance : quelles sont les tests à réaliser qui valideront que la user-story est valide ?

Des user-story 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-story 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 faire passer 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 personas, des user-story unitairement… Ce qui compte, c’est que chaque user-story soit associées à l’une des Hypothese and Measure définit.

Definition of Done

Le Product Owner et les développeurs définissent ensemble ce que sera une user-story « Done » (que le Product Owner pourra passer dasn « Done ») avec les mêmes potentiels critères cités dans la Definition of Ready.

Il est conseillé de mettre des tests d’acceptance dans la definition of ready et dans la definition of done (car nous voyons mal comment le Product Owner va faire pour les écrire entre les deux).

Les tests unitaires : technique qui permet de tester chaque fonction séparément pour assurer que celle-ci fonctionne bien à chaque mise en production. L’intérêt de cette demande est surtout pour la Definition of Done.

Voici un article que j’ai écrit sur le sujet : La qualité du produit avec de la TDD

Conclusion

Le Product Owner et les développeurs vont eux même définir la qualité du travail attendu grâce à la Definition of Done et la definition of Ready.

Quelles sont vos pratiques chez vous pour définir un user-story Ready et une user-story Done ?

4 réponses sur “Faire la Definition of Done des user-story”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *