La « Definition of Done » ou « DoD » ou « Définition de Fini » fait partie des artefacts de Scrum depuis la toute première version du Scrum Guide en 2010. Celle-ci permet de s’assurer qu’un certain nombre de critères sont respectés avant de considérer qu’un élément du Product Backlog est terminé.
Mais par qui doit-elle être créée ? Qu’est ce qui la compose et qui en est responsable ? C’est ce que nous allons voir dans l’article !
La Definition of Done et ses objectifs
Que veut dire “Terminé” ? On peut croire que la notion de “terminé” est objective et commune pour tous. Mais il existe des cas où nous serions peut-être moins unanimes sur sa définition. Par exemple, au cinéma, un certain nombre de personnes considèrent le film comme terminé lorsqu’apparait le générique. Pour moi, il s’agira de m’assurer qu’il n’y a pas de scène post générique à la fin de ce dernier (Merci Marvel !!!).
Et c’est là où, pour une équipe, lorsqu’un ensemble de critères ont été réalisés/respectés, la Definition of Done permet de savoir lorsqu’une story du Product Backlog est terminée. Elle permet d’aligner tous les participants sur LEUR conception de ce qui est fini et les critères importants qu’il faut respecter. Un incrément est ainsi constitué de tous les items qui respectent la Definition of Done.
La Definition of Done fait partie des outils qui permettent d’assurer un certain standard de qualité. Elle peut en plus être utile pour un nouvel arrivant, afin de lui présenter synthétiquement les critères importants à avoir en tête lorsqu’il se met à travailler sur un item. Cette transparence qu’elle apporte peut aussi être partagée au métier ou toute personne qui s’intéresserait aux critères qui ont été respectés pour valider un sujet. Ce qui en fait un parfait outil d’alignement.
Ces critères vont aussi permettre de faciliter l’estimation de la complexité d’un besoin. Sans ces derniers, on pourrait être amenés à faire des interprétations ou des “raccourcis” (par exemple en n’estimant que le développement). Comme la Definition of Done liste les critères de complétion (documentations, requis techniques, procédure de test), les tâches annexes au développement sont plus facilement visibles, compréhensibles et estimables.
La construction de la Definition of Done
La Definition of Done doit être créée par les membres de la Scrum Team, et si plusieurs Scrum Teams travaillent sur le même produit, ils doivent la créer collégialement et s’engager à la respecter. Ensuite, le respect de son application sera à la main des Développeurs (la Dev Team).
De plus, la Definition of Done doit être challengée/modifiée empiriquement. Il est peu probable qu’une DoD qui n’a pas évoluée depuis un certain temps (6 mois ? 1 an ?) fasse toujours consensus au sein de l’équipe. Et rien que la reparcourir régulièrement permet de réaffirmer son importance et de s’assurer que toute le monde est aligné sur la même vision de ce qui est attendu.
Une Définition of Done peut être représentée comme une checklist dont voici quelques exemples :
- Le développement est terminé et le Code Review effectué
- Des Tests Unitaires ont été mis en place et assurent une couverture de 80% du code
- Les tests de bout en bout ont été réalisés
- Les tests automatisés ont été créés/adaptés
- La couverture de code en Tests Unitaires est restée stable ou a augmenté
- La fonctionnalité est intégrée avec le reste du Produit
- La dette technique a été réduite ou est stable
- Les critères d’acceptation sont validés (ou respectés ?)
- Les temps de chargement respectent les SLA
Votre Board Kanban peut être une source d’idée pour intégrer certains critères.
Pour vous aider à préparer cette DoD, le jeu de cartes DOD Kards (créé par Thomas Wallet et Camilo Velasquez) ou l’atelier proposé récemment par Jean-Christophe Pagès, peuvent vous aider/inspirer.
Extrait de cartes du jeu “DOD Kards”
Et comme je l’évoquais plus haut, elle n’est pas figée dans le temps, tester de nouveaux critères à respecter si nécessaire et débriefez quelques sprints plus tard de leurs légitimités ou non à les conserver dans cette liste.
Et si tous les membres de l’équipe ne sont pas d’accord ?
Si différents membres de l’équipe ne sont pas d’accord par rapport à certains critères de la Définition of Done, il peut être intéressant d’indiquer :
- Pourquoi nous souhaitons intégrer ce critère à la liste ? Si c’est pour pallier à un problème rencontré par le passer, l’ajout de ce critère semble être facilement justifiable.
- Les gains/les avantages qu’apporterait l’ajout de ce critère.
- Les inconvénients qu’apporterait l’ajout de ce critère.
Si besoin, testez ce nouveau critère quelque temps et faites le point quelques sprints plus tard.
Conclusion
La Definition of Done est un artefact du Framework Scrum, garantissant qualité, transparence et vision partagé de la ou les Scrum Teams qui l’appliquent.
Elle n’est pas à consulter au moment de fermer le ticket, mais plutôt à garder en mémoire à chaque étape de réalisation, que ce soit pour l’estimation d’un élément, pour sa réalisation ou sa validation.
C’est ce qui fait qu’elle est respectée qui fait que votre incrément prend vie. Charge à vous de la faire évoluer ensuite, pour qu’elle reste toujours adaptée au contexte concerné et à ceux qui sont chargés de l’appliquer.
Ha, avant de partir, connaissez-vous la Definition of Ready, la liste des critères qui définissent quand un ticket est prêt à être développé ?
