Définition de « terminé » (Definition of Done - DoD)

La définition de « terminé » (Definition of Done - DoD) est un autre accord crucial et partagé au sein d'une équipe agile.

Elle sert de liste de contrôle (checklist) qui établit les critères qu'un élément du backlog (comme une histoire utilisateur) ou un incrément de produit doit remplir pour être considéré comme entièrement terminé.

Contrairement aux critères d'acceptation (spécifiques à chaque histoire), la DoD est une norme unifiée qui s'applique à tout le travail effectué par l'équipe.

Son objectif est de créer une compréhension commune et transparente de la qualité et de l'exhaustivité attendues, en évitant les ambiguïtés et le problème du travail « presque terminé ».

Garantir la qualité et l'exhaustivité de l'incrément

L'objectif principal de la DoD est de garantir la qualité et de s'assurer que lorsque l'équipe déclare quelque chose comme « terminé », c'est réellement le cas, sans laisser de travail en suspens caché.

Cela permet d'éviter les situations dans lesquelles une fonctionnalité est considérée comme terminée du point de vue du codage, mais où des étapes importantes telles que des tests approfondis, des révisions de code, la mise à jour de la documentation ou le nettoyage du code sont encore manquantes.

Le DoD définit toutes les activités nécessaires pour qu'une augmentation de produit soit potentiellement livrable et de haute qualité, en garantissant qu'aucune dette technique inutile ne s'accumule et que le travail respecte les normes convenues par l'équipe.

Création collaborative de la liste de contrôle DoD

Tout comme la définition de « prêt », la DoD n'est pas imposée, mais doit être créée et convenue de manière collaborative par toute l'équipe Scrum (ou équipe agile).

Elle est définie à travers une discussion au cours de laquelle l'équipe établit ses propres normes de qualité et d'exhaustivité.

Cette liste de contrôle est unique à chaque équipe et à son contexte.

Les éléments communs qui sont généralement inclus dans une DoD sont les suivants :

• Code terminé.
• Révisions du code effectuées.
• Tests unitaires écrits et réussis (souvent avec un pourcentage de couverture minimum).
• Tests d'intégration effectués.
• Tests de régression réussis.
• Tests d'automatisation mis à jour (avec un pourcentage de couverture).
• Documentation nécessaire mise à jour.
• Acceptation par le propriétaire du produit.
• Révision et acceptation par le concepteur UX (le cas échéant).

La liste doit être claire, mais pas trop complexe afin de ne pas devenir bureaucratique. Il peut s'agir d'une liste physique ou d'un accord commun.

DoD et son impact sur l'estimation

Une DoD claire et partagée a un impact direct et positif sur l'estimation du travail.

Lorsque l'équipe estime une histoire utilisateur (par exemple, à l'aide de points d'histoire), elle doit non seulement tenir compte de l'effort de codage, mais aussi de tout le travail nécessaire pour respecter le DoD.

Cela inclut le temps nécessaire pour les tests, la documentation, les révisions, etc.

Sans une DoD claire, les estimations peuvent