Definition of Done (DOD)

Definition of Done
Definition of Done

En Scrum (voire d’autres méthodes), nous aimons proposer des user-stories 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 coachs agiles aiment beaucoup faire un atelier pour définir le « Ready » et le « Done » qui permet de définir le Definition of Done (Dod).

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-stories 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 que nous pouvons retrouver régulièrement :

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

Mettre des tests d’acceptance : quels 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-stories 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 partager 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 personae, des user-stories unitairement… Ce qui compte, c’est que chaque user-story soit associée à 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 » ; en gros, ce sont les critères à valider pour autoriser le product owner à passer une demande dans « Done ». Ils feront cela ensemble dans un atelier pour définir le Definition of Done.

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

Les tests unitaires : pratique qui permet de tester chaque fonction séparément pour assurer que celles-ci fonctionnent 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

Dans le definition of done, il vous faudra définir aussi si votre code sera en recette ou en livraison. Mettre la « mise en production » comme critère de definition of done relève d’une très grande maturité technique des équipes.

Article : Est-ce que le « Done » contient la mise en production ?

Conclusion definition of done (dod) en scrum

Le Product Owner et les développeurs vont eux même définir la qualité du travail attendu. Pour cela, ils vont définir la Definition of Done et la definition of Ready.

Quelles sont vos pratiques chez vous pour définir une user-story Ready et une user story Done ? Partagez vos astuces du definition of done (dod) ou du definition of ready (dor).

[ Article lu 4 fois aujourd'hui ]
A propos Judicaël Paquet 491 Articles
  Paquet Judicaël (coach agile et devops sénior) Mes activités en France et en Suisse : - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile. [Suisse/France]