La definition of done est un sujet important afin de réussir ses projets agile, qui donne généralement lieu à des débats animés dans l’équipe pour savoir ce qu’il faut mettre ou non dans cette définition.
Pour couper court aux discussions, je vous livre dans cet article 11 conseils d’experts qui vont vous permettre de rédiger une definition of done efficace et directement applicable dans votre contexte.
C’est quoi une definition of done ?
La definition of done est une checklist de critères à vérifier permettant de s’assurer qu’une user story est réalisée à 100% dans un contexte agile. Cette pratique permet d’assurer un niveau d’exigence de qualité minimum tout au long du projet.
Dans un contexte agile, l’équipe ne s’engage pas sur une quantité de travail à effectuer (le nombre d’items intégrés au sprint backlog). Elle s’engage sur ce que signifie un incrément de qualité via cette definition of done.
Elle évolue au fur et à mesure des itérations et des besoins qui émergent. Elle est mise à jour lors des rétrospectives de l’équipe Scrum.
Pour aller + loin : Qui rédige la definition of done ? Quand faut-il la créer ou la mettre à jour ? Comment la gérer lorsqu’on a plusieurs équipes ? Je réponds à toutes vos questions sur la definition of done dans cet article.
11 conseils pour rédiger une definition of done efficace
Avant de vous livrer mes conseils, sachez qu’une definition of done doit refléter le travail à réaliser pour qu’une user story soit considérée comme terminée et devienne un incrément.
Il n’y a pas de « presque fini », « fini à 99% », ou que sais-je encore. Soit c’est fini, soit ça ne l’est pas.
Et la definition of done est précisément là pour décrire ce que veut dire fini. C’est un vecteur de transparence dans l’équipe et en dehors de l’équipe. Elle élimine ainsi l’ambiguïté et le flou qui peut régner dans l’équipe.
1 ) Ce qui est écrit doit être fait
Vous devez être inflexible avec la definition of done : ce qui est écrit, on le fait !
« Il reste 1 ligne de code ou 1 paragraphe dans la doc à faire, c’est l’affaire de 5 minutes » n’est pas une excuse valable.
Déjà parce qu’on a tendance à sous-estimer le reste à faire. Ces 5 minutes pourraient biens e transformer en plusieurs heures.
Ensuite parce que s’il ne reste qu’une seule ligne de code à compléter, pourquoi est-ce qu’on se parle ?
Il reste quelque chose à faire ? Alors ce n’est pas terminé.
Ne descendez jamais le niveau d’exigence pour finir dans les temps. Certes, vous aurez tenu les délais , mais à quel prix ? Celui de la qualité de votre incrément (le résultat du sprint). Et de la confiance de votre client, qui aura de sérieux doutes sur votre capacité à livrer de la valeur sur les prochains sprints.
La definition of done, ce n’est pas une bonne résolution. Le Scrum Guide décrit d’ailleurs cette notion comme un engagement de l’incrément. C’est donc un artefact de transparence.
2 ) La definition of done peut et doit évoluer
La definition of done n’est pas quelque chose de statique. Elle évolue dans le temps, au fur et à mesure des itérations. Elle évolue en même temps que le contexte projet évolue. Elle évolue en fonction de l’apprentissage de l’équipe Scrum.
Un critère d’achèvement dans la definition of done n’est plus utile ? Faites-le sauter.
Un besoin émerge en cours de projet ? Ajoutez-le à la definition of done.
Par contre, soyons clairs. Bien qu’elle évolue en cours de projet, la définition de fini ne doit JAMAIS être modifiée en cours de sprint.
Pourquoi ? Car ce qui était considéré comme terminé avant la modification peut subitement se retrouver comme à faire.
Le bon moment pour discuter de la modification de la definition of done, c’est la rétrospective.
3 ) S’inspirer des autres équipes
Vous souhaitez établir votre definition of done mais vous ne savez pas par où commencer ?
Inspirez-vous des autres équipes de votre organisation. Parcourez les blogs agiles et les retours d’expérience sur le web.
Partez d’une base simple et faites-la évoluer en cours de route en fonction de vos propres besoins.
Mais ne recopiez pas bêtement une définition de fini parce qu’elle vous semble sympa.
Posez-vous toujours la question : « Pourquoi ? »
Pourquoi ont-ils ajouté ce critère dans la definition of done ? Pourquoi est-ce logique de procéder comme ça ? Est-ce que ça a du sens que je le conserve ?
4 ) Garder la definition of done la plus petite possible
Le mieux est l’ennemi du bien. Surtout au début de votre projet et sur les premiers sprints.
A trop vouloir en mettre dans la definition of done, vous risquez de ne rien réussir à terminer.
Préférez partir d’une base simple mais solide, que vous ferez ensuite évoluer dans le temps.
La bonne pratique est de garder la definition of done la plus simple et la plus petite possible, et de la laisser émerger au fur et à mesure des itérations en fonction des vrais besoins.
5 ) Effectuer un checkup de la definition of done régulièrement
La definition of done n’est pas statique : elle évolue dans le temps.
Je vous recommande donc d’effectuer un checkup régulièrement pour vous assurer que la definition of done répond toujours à vos besoins.
La rétrospective est le moment parfait pour cela.
Voici quelques questions que vous pouvez collectivement vous poser :
- Y a t-il des critères qui n’ont plus d’intérêt dans la definition of done et qu’il faudrait supprimer ?
- Est-ce qu’on doit l’assouplir ? Et si oui comment ?
- Est-ce qu’on doit la durcir ? Et si oui comment ?
- Quelle est la dernière fois que la definition of done a été mise à jour ?
- Quel est l’impact de ne pas respecter ce critère ?
- A t-on des exemples de user stories qui n’ont pas respectées la definition of done ?
- A t-on des exemples de user stories problématiques pour lesquelles la definition of done n’était pas suffisante ?
- Quel est l’impact si on ajoute tel critère à notre definition of done ?
6 ) Partager la même definition of done entre équipes
L’agilité à l’échelle, c’est à dire collaborer entre plusieurs équipes agiles sur un même produit, est un challenge et apporte son lot de difficultés.
Parmis celle-ci, on retrouve la notion de qualité. Si chaque équipe dispose de sa propre définition de fini, il va bien falloir fusionner le travail à un moment donné. Et c’est souvent là que le bat blesse.
La qualité de l’incrément de chaque équipe peut être au top, mais la qualité de l’incrément produit peut être déplorable, car rien n’a été pensé pour fonctionner ensemble.
Voici ce que je vous propose pour éviter cela :
- Mettez en place une definition of done commne à toutes les équipes.
Cette DoD décrit les critères d’achèvement minimum que l’ensemble des équipes doivent respecter. - Laissez le champ libre aux équipes pour être plus strictes si elles le souhaitent.
Chaque équipe peut décider de créer sa propre definition of done, en partant de la définition de fini commune. La seule règle : que la DoD de l’équipe soit plus stricte que la commune. - Utilisez les partages et retours d’expériences entre équipes pour renforcer la definition of done.
Lorsque quelque chose marche bien dans une équipe, il est intéressant de le partager et de le vendre aux autres afin d’enrichir leur pratique de l’agilité. Cela pourra également donner lieu à un nouveau socle de base pour l’organisation.
7 ) Consulter le Product Owner
Soyons clair : une definition of done ne doit jamais être décrétée par qui que ce soit sans consultation : ni l’équipe de développement, ni le product owner, ni le scrum master.
Pour qu’une definition of done soit valable, elle doit émerger à partir d’un travail collaboratif de l’équipe Scrum et doit être validée et acceptée par tous.
Le Product Owner peut émettre des recommandations, tuot comme le Scrum Master, mais l’équipe de développement aura le mot final.
8 ) Rapprocher le plus possible la definition of done de la mise en production
On n’a pas tous la même notion d’un travail terminé : pour certains, c’est le code rédigé à 100%, pour d’autres c’est code rédigé + testé. Pour d’autres encore, c’est le même code mais mis en production.
La mise en production n’est pas toujours possible en fonction des situations. Je le conçois.
Parfois, on attend d’avoir plusieurs incréments de sprint pour effectuer une nouvelle release d’un produit (les fameuses mises à jour de logiciels par exemple).
Mais vous pouvez préparer la mise en production, rédiger les documents qui vont bien, tester votre processus de mise en production sur un banc de test ou sur un environnement de recette.
Bref, il y a plein d’actions que vous pouvez mener pour vous assurer que le jour J, vosu n’aurez aucun problème lors de la mise en production.
Je vous conseille donc dans votre definition of done de vous rapprocher le plus possible que vous pouvez de la mise en production.
9 ) Ne pas fixer des critères inatteignables
Il faut parfois savoir lâcher du lest. A quoi ça sert de fixer des critères d’achèvement hyper stricts si vous savez pertinemment que vous ne pouvez pas les atteindre pour l’instant ?
A trop vouloir faire parfait, vous ne sortirez jamais rien.
Il faut bien livrer l’incrément à un moment ou un autre pour obtenir du feedback de la part des utilisateurs.
Gardez à l’esprit que la definition of done reflète ce qu’est un travail terminé à 100% à un instant t. Ce n’est pas un objectif ambitieux que l’équipe devrait essayer d’atteindre. C’est ce l’équipe est en capacité de faire à l’heure actuelle.
C’est pour cela que je vous recommande de garder une definition of done la plus light possible.
10 ) Utiliser les DoD Kards
DoD Kards est un jeu de cartes qui permet de réfléchir et de parvenir à un consensus sur ce que doit être la definition of done de l’équipe.
Les DoD Kards sont une création de Kleer, par Camilo Velasquez et Thomas Wallet, inspirées de Definition of Done Exercise de David A. Koontz, et sont distribuées sous license Creative Commons Attribution-ShareAlike 3.0 Unported.
Quelques cartes tirées du jeu DoD Kards
Composition du jeu DoD Kards
Le jeu DoD Kards est composé de :
- 24 cartes critères.
Elles représentent des critères d’achèvement pouvant potentiellement faire partie de votre definition of done. Certaines de ces cartes sont vierges pour y inscrire vos propres critères. - 3 cartes choix :
- « Oui », pour les critères à inclure dans la definition of done.
- « Plus tard », pour les critères à considérer mais ne pouvant pas être inclus pour le moment. « On aimerait bien le faire, on va se donner l’objectif de ».
- « Non », pour les critères ne pouvant pas être appliqués.
Les règles du jeu DoD Kards
Planifiez un atelier (ou un serious game, vous l’appelez comme vous voulez) DoD Kards, et réunissez les membres de l’équipe de développement ainsi que le product owner.
Le jeu se déroule comme suit :
- Faites 3 colonnes en plaçant les trois cartes de choix : oui, plus tard, non.
- Mélangez toutes les cartes de critère, sauf les jaunes.
- Chacun leur tour, chaque joueur :
- Prend la première carte critère et la lit à haute voix.
- Puis il place cette carte dans une des 3 colonnes.
- Si quelqu’un n’est pas d’accord, l’équipe en discute jusqu’à arriver à un consensus. Si au bout de 5 minutes, le consensus n’est pas trouvé, alors la carte est placée dans la colonne Non.
- Répétez les étapes précédentes jusqu’à épuisement des cartes.
- A n’importe quel moment, un joueur peut décider de prendre une carte jaune et d’y inscrire un critères personnalisé qui n’existe pas dans le jeu afin de le proposer.
On classe les cartes en 3 catégories
Dans quel contexte utiliser les DoD Kards ?
L’utilisation des DoD Kards est particulièrement indiquée si votre équipe Scrum a du mal à tenir des engagments, ou si elle galère à définir sa propre definition of done.
11 ) Vérifier que toutes les user stories disposent de critères d’acceptation
Je vous conseille d’ajouter à votre définition de fini en plus de vos critères d’achèvement le critère supplémentaire suivant :
- Respecter les critères d’acceptation de la user story.
Et oui, chaque user story a un ou plusieurs critères d’acceptation à respecter pour qu’elle soit valable d’un point de vue métier.
C’est donc une pratique de vérifier cela dans la definition of done.
Attention toutefois :
Dans ce cas, respecter la définition de réalisé permet de s’assurer que les critères d’acceptation sont respectés. Mais l’inverse n’est pas vrai. Respecter les critères d’acceptation d’une user story ne peut pas garantir le respect de la definition of done.
Critères d’achèvement vs Critères d’acceptation
Il existe deux types de critères qui permettent de définir la qualité d’un travail :
- Les critères d’achèvement.
Ils représentent les critères à respecter pour qu’un travail soit terminé à 100%. C’est ce qu’on appelle communément la definition of done, ou définition de fini. Ils s’appliquent à l’ensemble des éléments du backlog. - Les critères d’acceptation.
Ils sont uniques et associés à une seule user story. Ils indiquent les conditions de satisfaction métier qui permettent de satisfaire l’utilisateur. Un critère d’achèvement sur la definition of done peut être de respecter tous les critères d’acceptation de la user story.
J’attire votre attention sur un point :
Respecter la definition of done permet de s’assurer que les critères d’acceptation sont respectés. Mais l’inverse n’est pas vrai.
Respecter les critères d’acceptation d’une user story ne peut pas garantir le respect de la definition of done.
