Guide Scrum | 22. Critères d’acceptation des user stories

La User Story est une technique permettant aux entreprises de livrer des produits et des services répondant au maximum aux besoins des clients. Les critères d’acceptation de la User Story améliorent l’évaluation des nouvelles fonctionnalités du produit du point de vue de l’utilisateur.

Critères d’acceptation de la User Story – table des matières :

1. Introduction
2. Comment formuler les critères d’acceptation de la User Story ?
3. Critères d’acceptation de la User Story vs. Définition de Terminé
4. Résumé

Introduction

Nous avons couvert la User Story et les problèmes à traiter lors de sa création dans des articles précédents. Aujourd’hui, cependant, nous allons nous concentrer sur les critères d’acceptation de la User Story.

Les critères d’acceptation doivent suivre ces directives :

• décrire la nouvelle fonctionnalité améliorée du produit du point de vue de l’utilisateur
• être unique pour chaque User Story

Le guide Scrum officiel ne définit pas la User Story et ses critères d’acceptation. Ils sont optionnels, mais très courants dans le travail Scrum. Néanmoins, pour satisfaire la curiosité de nos lecteurs, nous les décrirons comme : Les conditions qu’une amélioration de produit doit respecter pendant un Sprint donné pour obtenir l’approbation de l’utilisateur.

Comment formuler les critères d’acceptation de la User Story ?

Une User Story bien écrite contient une description claire du contexte ou de la situation concernée, respectant ainsi les critères d’acceptation. Cependant, c’est juste une phrase courte, trop vague et ambiguë pour identifier directement les considérations nécessaires.

Clarté et accessibilité des critères d’acceptation

Par conséquent, pour éviter les ambiguïtés, menez et enregistrez une conversation détaillée avec le client pour déterminer l’objectif de la solution mise en œuvre. N’oubliez pas que la formulation finale des critères d’acceptation appartient au Product Owner.

Notez-les avec les critères de la User Story avant la planification du Sprint. Chaque membre de l’équipe Scrum doit le lire et confirmer qu’il comprend et accepte les critères d’acceptation de la User Story. En général, les critères d’acceptation se trouvent au verso de la carte de la User Story.

Des critères d’acceptation correctement formulés permettent à l’utilisateur de vérifier si le test de la User Story suit sa description. Les critères peuvent prendre la forme d’une liste de contrôle avec des points à cocher une fois complétés lors des tests du produit à la fin d’un Sprint.

La question est simple si le fonctionnement du produit est transparent pour l’utilisateur. Cependant, plus le produit est complexe, plus il devient difficile à tester. Prenez des logiciels complexes ou des services à grande échelle. Par conséquent, dans la plupart des cas, un outil utile pour valider la User Story est de préparer un test d’acceptation.

Test d’acceptation

Si vous décidez de développer un test d’acceptation, notez-le au verso de la carte contenant la User Story. Plus tard, l’équipe Scrum ou une équipe QA externe peut le réaliser.

Le test doit avant tout contenir une déclaration claire indiquant si le produit échoue ou réussit le test. Il ne peut pas contenir d’énoncés en pourcentage ou d’évaluations intermédiaires.

Si la User Story a plus d’un critère d’acceptation, chacun nécessite un test séparé. De cette manière, il est beaucoup plus facile de déterminer quelle fonctionnalité du produit nécessite une amélioration ou un perfectionnement, ce qui est particulièrement important si les nouvelles fonctionnalités incluses dans la User Story se chevauchent ou sont indépendantes les unes des autres.

Critères d’acceptation de la User Story vs. Définition de Terminé

La Définition de Terminé est une partie intégrante du travail en Scrum, qui est l’équivalent technique des critères d’acceptation. Cependant, vous ne devez pas confondre ces deux éléments car ils désignent des engagements différents. Qu’est-ce que la Définition de Terminé, et comment et quand la formuler est une question que nous avons abordée dans un article séparé ?

Ici, nous mentionnerons seulement que la Définition de Terminé est une description claire et transparente de l’état attendu du produit après l’achèvement de l’incrément dans le backlog produit. Elle décrit les améliorations apportées dans l’incrément. Cela contraste avec le critère d’acceptation correspondant à la User Story, qui décrit la fonctionnalité du produit créée lors du dernier Sprint telle qu’elle est perçue par le client.

Par exemple, prenons cette User Story avec le contenu :

En tant que client connecté d’une boutique en ligne, je veux acheter une baguette magique d’un simple clic.

La Définition de Terminé pour la User Story ci-dessus pourrait inclure les éléments suivants :

• la création d’un panneau de connexion pour les clients de la boutique
• l’intégration du système de paiement
• l’ajout du bouton de paiement instantané au modèle de page produit

D’autre part, les critères d’acceptation du client comprennent :

• la possibilité de se connecter à la boutique
• la possibilité de définir un mode de paiement par défaut
• un bouton “Acheter maintenant” fonctionnel pour le produit “baguette magique”

Résumé

Les critères d’acceptation sont un ensemble de conditions qui fonctionnent comme un moyen d’évaluer la mise en œuvre de la User Story. En décrivant les performances du produit nouvellement améliorées du point de vue de l’utilisateur, cette méthode devient un outil efficace pour travailler avec le client. Elle présente la performance de l’équipe Scrum du point de vue de l’utilisateur.

Des critères d’acceptation bien formulés, par exemple sous la forme d’un test d’acceptation, nous permettent également de vérifier lors d’un Sprint si la fonctionnalité créée répond aux exigences du client.

Les critères d’acceptation diffèrent de la Définition de Terminé principalement par la perspective qu’ils adoptent lors de leur expression. Ils ne contiennent pas de description des exigences techniques que la nouvelle solution doit respecter, mais seulement les fonctions que le produit doit présenter après la réalisation de la nouvelle User Story.

Si vous aimez notre contenu, rejoignez notre communauté de travailleurs acharnés sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.