Quelle est la différence entre user story et critères d’acceptation ?

Definition of Done (DoD)  est une liste d’exigences auxquelles une user story doit adhérer pour que l’équipe la qualifie de complète.  Alors que les  critères d’acceptation  d’une User Story consistent en un ensemble de scénarios de test qui doivent être remplis pour confirmer que le logiciel fonctionne comme prévu.

La différence entre ces deux est que  le DoD est commun à toutes les User Stories alors que les critères d’acceptation s’appliquent à des User Story spécifiques . Les critères d’acceptation de chaque User Story seront différents en fonction des exigences de cette User Story.

En d’autres termes,  les critères DoD et d’acceptation doivent être remplis pour compléter la User Story.  L’incrément de produit n’est pas considéré comme complet, à moins que ces deux listes ne soient faites. Ainsi, nous devons définir deux aspects de la Définition du Terminé (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

Les objectifs de Definition of Done

• Construire une compréhension commune au sein de l’équipe sur la qualité et l’exhaustivité
• Utilisez-le comme une liste de contrôle par rapport à laquelle les User Stories (ou PBI) sont vérifiées
• Assurez-vous que l’incrément expédié à la fin du  Sprint  est de haute qualité et que la qualité est bien comprise par toutes les personnes impliquées.

Exemple — Définition de Terminé

Par exemple, dans l’industrie du logiciel, les équipes peuvent avoir besoin de poser certaines des questions suivantes pour établir leur DoD :

• 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.

Les objectifs des critères d’acceptation

• Clarifier ce que l’équipe doit construire avant de commencer à travailler
• Assurez-vous que tout le monde a une compréhension commune du problème
• Aidez les membres de l’équipe à savoir quand l’histoire est terminée
• Aidez à vérifier l’histoire via des tests automatisés.

Exemple — Critères d’acceptation

• Un utilisateur ne peut pas soumettre un formulaire sans remplir tous les champs obligatoires
• Les informations du formulaire sont stockées dans la base de données des inscriptions
• Le paiement peut être effectué par carte de crédit
• Un e-mail d’accusé de réception est envoyé à l’utilisateur après avoir soumis le formulaire

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.

Les références

• Définition de Terminé vs Critères d’acceptation
• Qu’est-ce que la cartographie des histoires d’utilisateurs ?
• User Story vs cas d’utilisation pour le développement logiciel agile