Dans le framework agile Scrum, la Definition of Done décrit la liste des exigences sur lesquelles l’équipe s’accorde et qui doivent être respectées pour considérer une user story ou un autre élément du backlog comme terminé. Dans cet articles nous allons voir les critère de Definition of Done, les avantages de cette aproche et les erreurs à éviter.
Les critères du Definition of Done
Les critères spécifiques peuvent varier selon l’équipe, mais la checklist typique d’une équipe agile pour la Definition of Done inclut :
• Le code est terminé et répond aux exigences business et fonctionnelles.
• Les tests sont achevés, avec soit aucun défaut identifié, soit des défauts acceptables pour cette release.
• La documentation est complétée.
• L’item (user story, feature, etc.) est prêt pour la release.
Cette définition est utilisée par l’ensemble de l’équipe afin de s’accorder sur le niveau global de qualité et de complétude qu’une fonctionnalité et plus largement qu’un produitdoit posséder. Il s’agit donc d’un ensemble large de critères qui peut s’appliquer à tous les éléments du backlog (par exemple, la qualité).
Quels sont les avantages du definition of done ?
Il existe de nombreuses raisons pour lesquelles une équipe Scrum pourrait vouloir mettre en place l’approche de la Definition of Done pour son travail sur les items du backlog.
1. Elle aide l’équipe à réaliser des progrès constants et prévisibles
En possédant une liste claire et concrète de critères à respecter pour considérer le travail comme terminé, l’équipe agile peut planifier plus efficacement sa charge de travail. Elle peut estimer les délais d’achèvement, se concentrer sur l’essentiel et, par conséquent, est moins susceptible de s’écarter de sa trajectoire ou de manquer des deadlines pendant les sprints.
2. Elle augmente la précision des estimations pour l’équipe cross-fonctionnelle
La Definition of Done clarifie ce que l’équipe agile doit accomplir pour considérer un projet comme terminé. Cela permet à l’équipe d’offrir une transparence accrue à l’ensemble de l’organisation. En effet, puisque l’équipe partage une compréhension commune de ce à quoi ressemblera le produit final (Done et releasable), elle pourra fournir des estimations plus précises aux parties prenantes externes quant au moment où les projets seront achevés.
3. Elle permet une meilleure collaboration au sein de l’équipe
Lorsqu’elle se réunit pour discuter du travail à venir (pendant le sprint planning) , une équipe Scrum avec une Definition of Done commune dispose déjà d’une vision partagée des exigences associées à chaque item du sprint. Cela facilite grandement la répartition des tâches, la collaboration cohésive et, au final, le développement constant de produits de haute qualité.
3 erreurs fréquentes que les équipes agiles font avec la definition of done.
1. Inclure des exigences qui échappent au contrôle de l’équipe.
Une erreur commune faite par les équipes agiles consiste à inclure comme exigences des approbations de parties prenantes extérieures à l’équipe produit. Si la Definition of Done requiert une validation par des entités externes, l’équipe produit ne dispose plus du contrôle total sur le moment ou la possibilité de considérer son travail comme terminé.
Tel qu’expliqué par Scrum.org, cela illustre parfaitement la différence que l’on peut faire en termes produit entre « shippable » et « releasable ». Une user story ou un incrément de produit peut être considéré comme « shippable » quand l’équipe produit a terminé toutes les tâches convenues pour cet item. Cependant, à ce stade, l’item devra encore passer par un processus d’approbation avec des parties prenantes additionnelles. L’équipe pourrait alors décrire cette phase comme sa Definition of Almost Done.
Une fois que ces parties prenantes ont validé, l’équipe considérera que la user story ou l’item est releasable. Ce sera alors sa Definition of Done.
2. Ajouter un niveau de détail excessif dans la liste des exigences.
Une autre erreur fréquente consiste à rédiger une liste très détaillée de critères pour obtenir un état « Done ». Trop d’exigences ou de détails peuvent ralentir l’avancement de l’équipe tout en générant confusion et désaccord entre membres d’équipe.
Une Definition of Done efficace doit décrire uniquement les étapes minimales requises pour faire passer une user story ou un autre item du backlog de l’état « en cours » à « terminé ». Pour rendre ce processus efficace et reproductible, l’équipe doit maintenir sa liste de critères à un niveau élevé. L’endroit idéal pour inclure un ensemble détaillé d’exigences pour un projet donné est l’Acceptance criteria, qui spécifie les exigences précises nécessaires pour un travail spécifique.
La Definition of Done de l’équipe peut évoluer avec le temps et inclure davantage d’exigences à mesure que l’équipe gagne en compétence et en cohésion. Cependant, lors de l’élaboration de sa première liste de critères, l’équipe doit adopter une approche minimale et ne retenir que les exigences essentielles pour passer un item du backlog à l’état « Done ».
3. Se contenter d’une liste de critères verbale.
Pour que l’approche de la Definition of Done soit efficace, l’équipe agile doit rendre explicite sa liste d’exigences. Idéalement, elle doit être affichée dans un endroit visible afin que l’équipe puisse la consulter quotidiennement.
Comme l’explique Agile Alliance, si l’équipe ne dispose que d’un accord verbal sur ce que signifie terminer une tâche, la Definition of Done perdra une grande partie de son efficacité. Une portion significative de la valeur de cette approche repose sur le fait que ce soit un accord écrit et partagé au sein de l’équipe, définissant les critères nécessaires pour considérer un projet comme terminé. L’équipe doit également pouvoir consulter ces critères régulièrement.
