Critères d’acceptation – Partie 2 de la user story / Blogs / Perficient

Ce blog est le deuxième article d’une série sur l’exploitation Histoires d’utilisateurs pour améliorer les résultats des produits. Dans cet article, nous explorerons comment les critères d’acceptation peuvent être utilisés pour définir la portée et les exigences des user stories.

Quels sont les critères d’acceptation ?

Les critères d’acceptation, ou AC, sont le niveau minimum d’attentes qui doivent être satisfaits pour marquer une user story comme complète. Il contient les situations, les déclencheurs, les résultats attendus et le rôle de l’utilisateur. D’une certaine manière, ils constituent une extension de la user story, qui permet de clarifier le résultat attendu avant le début du travail de développement.

Pourquoi les critères d’acceptation sont-ils importants ?

En tant que Product Owner, les critères d’acceptation sont un outil précieux pour communiquer efficacement les attentes d’une user story lorsque vous travaillez avec des équipes interfonctionnelles. Un AC aide les développeurs et les testeurs à comprendre ce qui doit être accompli, tandis que la user story fournit le contexte commercial et utilisateur d’origine. Développer un AC permet de penser en termes absolus, presque comme des instructions système, pour donner aux développeurs le contexte nécessaire pour exécuter une user story. Cela élimine toute ambiguïté et aide les développeurs et les testeurs à comprendre ce qui est attendu.

L’ajout de critères d’acceptation augmente la transparence entre un scénario commercial et le résultat souhaité. Il établit la base de ce qui devrait être testé. Il est important de noter que les critères d’acceptation ne sont pas les mêmes que ceux des cas de test, mais ils peuvent être utilisés pour éclairer les cas de test.

Comment formater les critères d’acceptation

Semblable à l’écriture de user stories, la pratique rend parfait. Agile fournit des cadres et des lignes directrices qui peuvent être utilisés comme éléments de base d’un critère d’acceptation réussi. Ce sont d’excellents points de départ, mais il est important d’adapter le cadre aux besoins uniques de votre organisation et de vos équipes.

La méthode Gherkin, comme démontré ci-dessous, est l’approche la plus courante pour créer des critères d’acceptation.

Compte tenu d’un certain scénario/contexte,

QUAND un certain déclencheur/action est pris,

ALORS un résultat doit être observé.

Par exemple:

Étant donné qu’un utilisateur se trouve à une étape après l’étape 2 du flux de paiement,

QUAND l’utilisateur clique sur le bouton de sortie

ALORS, le système affichera une invite de confirmation pour confirmer si l’utilisateur souhaite continuer.

Les autres options pour capturer le courant alternatif sont :

1. Format « Le système doit… », par exemple : Le système doit afficher une invite de confirmation lorsque l’utilisateur clique sur le bouton « Annuler ».
2. Énoncés d’exigences supplémentaires, par exemple,
   1. L’invite de confirmation doit comporter les composants d’interface utilisateur suivants :
      1. Deux options pour l’utilisateur
         1. Pour continuer l’action sélectionnée
         2. Annuler l’action sélectionnée
      2. L’invite doit suivre les directives de marque de l’organisation comme sur le marché.
      3. L’interface utilisateur doit respecter les normes d’accessibilité Web décrites dans le document d’accessibilité .

Critères d’acceptation Meilleures pratiques

Voici quelques bonnes pratiques pour créer des critères d’acceptation qui ont un impact :

• Soyez aussi précis, précis et concis que possible.
• Essayez de vérifier si les étapes que vous avez décrites sont effectivement testables.
• Utilisez des flux visuels, si cela a du sens, pour aider les lecteurs à comprendre la situation dans son ensemble.
• Utilisez des références à la documentation pertinente ou aux user stories sur lesquelles vous vous basez. Par exemple, la valeur commerciale, si elle n’est pas déjà évidente.

Comme pour toute autre documentation ou cérémonie agile, la collaboration donne un résultat de la plus haute qualité. Un Product Owner peut être responsable de l’élaboration de la version initiale des AC, mais la révision avec le reste de l’équipe lors de la préparation, du raffinement ou des cérémonies ponctuelles est une bonne pratique.

Il est également important de noter que la plupart des user stories seront approuvées ou signées par le Product Owner. Il est donc dans le meilleur intérêt d’un Product Owner de bien comprendre les attentes, l’impact et les risques associés aux user stories et comment ils va tester les AC. Dans certains cas, le PO n’est peut-être pas la personne à signer. Il doit s’assurer que les bonnes parties prenantes sont connectées.

Conclusion

L’élaboration de critères d’acceptation est une étape essentielle du cycle de vie du produit pour définir la portée et les exigences de vos user stories. Il fournit le contexte nécessaire pour aborder la user story sous un angle différent, afin de garantir que toutes les attentes ont été clairement communiquées.

Le prochain article de blog de cette série plongera dans des conseils supplémentaires sur les témoignages d’utilisateurs.

Perficient crée des solutions de produits numériques innovantes pour les entreprises Fortune 500 depuis plus de 25 ans. Contactez-nous aujourd’hui pour en savoir plus sur les services de conseil en innovation + développement de produits.