Guide de mêlée | 22. Critères d'acceptation des histoires d'utilisateurs

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

Critères d'acceptation des User Story - table des matières :

1. Introduction
2. Comment formuler les critères d'acceptation des User Story ?
3. Critères d'acceptation de la User Story par rapport à la définition de Done
4. Sommaire

Introduction

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

Les critères d'acceptation doivent suivre ces lignes directrices :

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

Le Scrum Guide officiel ne définit pas la User Story et ses critères d'acceptation. Ce sont des éléments facultatifs mais très courants du travail Scrum. Néanmoins, pour apaiser la curiosité de nos lecteurs, nous les décrirons comme suit : Les conditions qu'une amélioration de produit doit remplir au cours d'un sprint donné pour obtenir l'approbation de l'utilisateur.

Comment formuler les critères d'acceptation des User Story ?

Une User Story bien rédigée contient une description claire du contexte ou de la situation concernée, répondant ainsi aux critères d'acceptation. Pourtant, ce n'est qu'une courte phrase, 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 afin de déterminer l'objectif de la solution mise en œuvre. Rappelez-vous 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. Habituellement, les critères d'acceptation se trouvent au verso de la carte 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 puces à cocher lorsqu'elles sont remplies lors du test du produit à la fin d'un sprint.

L'affaire est simple si le fonctionnement du Produit est transparent pour l'Utilisateur. Cependant, plus le produit est complexe, plus il est 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 consiste à préparer un test d'acceptation.

Test d'admission

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

Le test doit d'abord et 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 de pourcentage ou d'évaluation intermédiaire.

Si la User Story comporte plusieurs critères d'acceptation, chacun nécessite des tests distincts. De cette façon, il est beaucoup plus facile de déterminer quelle fonctionnalité du produit doit être améliorée ou affinée et est particulièrement important si de 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 par rapport à la définition de Done

La définition de Done fait partie intégrante du travail dans Scrum, qui est l'équivalent technique des critères d'acceptation. Cependant, vous ne devriez pas confondre ces deux car ils dénotent des engagements différents. Quelle est la définition de Done, et comment et quand la formuler est un problème que nous avons couvert dans un article séparé ?

Ici, nous mentionnerons seulement que la Definition of Done est une description claire et transparente de l'état attendu du Produit après la réalisation de l'Incrément dans le Product Backlog. Il décrit les améliorations apportées au sein de l'incrément. Cela contraste avec le critère d'acceptation correspondant à la User Story, qui décrit la fonctionnalité Produit créée lors du dernier Sprint telle qu'elle est perçue par le Client.

Par exemple, prenez cette User Story avec le contenu :

En tant que client connecté d'une boutique en ligne, je souhaite acheter une baguette magique en un clic.

La définition de l'achèvement pour la User Story ci-dessus peut inclure les éléments suivants :

• la création d'un panneau de connexion pour les clients du magasin
• intégration du système de paiement
• ajouter le bouton de paiement instantané au modèle de page produit

D'autre part, les critères d'acceptation client comportent :

• la possibilité de se connecter au magasin
• la possibilité de définir un moyen de paiement par défaut
• bouton "Acheter maintenant" pour le produit "baguette magique"

Sommaire

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 nouveau et amélioré du point de vue de l'utilisateur, cette méthode devient un outil efficace pour travailler avec le client. Il présente les performances 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 améliore la satisfaction des demandes du Client.

Les critères d'acceptation diffèrent de la définition du fait principalement dans la perspective qu'ils adoptent sur l'expression. Ils ne contiennent pas une description des exigences techniques auxquelles la nouvelle solution doit répondre, mais uniquement les fonctions que le produit doit présenter après l'actualisation de la nouvelle User Story.

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Auteur : Caroline Becker

En tant que chef de projet, Caroline est experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Afficher tous les articles

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit