Définition de Terminé vs Critères d’Acceptation dans Scrum

La  définition d’achèvement  (DoD) est une liste d’exigences auxquelles la user story doit se conformer afin que l’équipe puisse l’invoquer comme complète.

Les  critères d’acceptation  des user stories comprennent un ensemble de scénarios de test qui répondront aux exigences pour confirmer si le logiciel fonctionne comme prévu.

Quand la user story sera-t-elle terminée ?

En d’autres termes, pour compléter les user stories, les critères de DOD et d’acceptation doivent être remplis. Les incréments de produit ne sont pas considérés comme complets tant que les deux listes ne sont pas complétées. Par conséquent, nous devons définir deux aspects de la définition du DoD – les critères d’achèvement et les critères d’acceptation :

Définition de terminé

La définition de Terminé est structurée comme une liste d’éléments, chacun utilisé pour valider une histoire ou un PBI, qui existe pour s’assurer que l’équipe de développement s’accorde sur la qualité du travail qu’elle tente de produire. Il sert de liste de contrôle utilisée pour vérifier  l’exhaustivité de chaque élément  du backlog de  produit (alias PBI) ou de l’histoire de l’utilisateur. Les éléments de la définition de « Terminé » sont destinés à s’appliquer à tous les éléments du Product Backlog, et pas seulement à une seule User Story.

Il peut être résumé comme suit :

• Le terme s’applique davantage à l’incrément de produit dans son ensemble
• Dans la plupart des cas, le terme implique que l’incrément de produit est livrable
• Le terme est défini dans le Scrum Guide
• Utilisé comme moyen de communication entre les membres de l’équipe
• Qualité globale du logiciel
• Si l’incrément est livrable ou non

Exemple — Définition de Terminé

• Code évalué par les pairs ?
• Codage terminé ?
• Code révisé ?
• Code enregistré ?
• Tests unitaires réussis ?
• Tests fonctionnels réussis ?
• Tests d’acceptation terminés ?
• Product Owner  revu et accepté ?

Critères d’acceptation

Les user stories sont l’un des principaux  artefacts de développement  pour  le développement Agile , mais  Scrum  n’exige pas explicitement l’utilisation des user stories ou des critères d’acceptation. Si un élément du backlog produit est considéré comme trop volumineux pour être mis dans un sprint, il sera normalement décomposé en user story, puis en un ensemble de tâches, comme illustré dans la figure :

Les User Stories encapsulent les critères d’acceptation, nous voyons donc souvent la définition des critères terminés et d’acceptation coexister dans notre processus de développement Scrum. La user story fournit le contexte de la fonctionnalité que l’équipe doit fournir. Les critères d’acceptation donnent des indications sur les détails de ladite fonctionnalité et sur la manière dont le client les acceptera. Les deux fournissent ensemble l’ensemble du livrable.

Certains des critères d’acceptation seront découverts dans les événements d’affinement du backlog en cours avant le début du sprint, et d’autres seront découverts juste après  la planification du sprint  lorsque vous vous asseyez pour avoir une conversation sur la user story dans une petite équipe. Les critères d’acceptation sont donc des attributs uniques à la User Story ou à l’élément de backlog de produit.

• Le terme s’applique à un PBI/Story individuel
• Les critères d’acceptation sont différents pour chaque PBI/Histoire
• Le terme n’est pas défini dans le Scrum Guide
• Utilisé comme un moyen de communiquer à toutes les personnes impliquées que les exigences pour un PBI/histoire particulier ont été respectées
• Aka tests d’acceptation, conditions de satisfaction, dans certains cas « cas de test », etc.

Exemple de User Story avec critères d’acceptation

La figure ci-dessous montre un exemple de critères d’acceptation d’une user story.