Comment Rédiger d’Excellents Critères d’Acceptation (Avec des Exemples)
Combien de fois avez-vous vu des développeurs et des testeurs se disputer sur la façon dont une fonctionnalité devrait fonctionner ? Et ces visages perplexes de développeurs qui ne savaient pas comment concevoir la fonctionnalité que vous aviez demandée ? Ces deux situations sont très répandues dans le monde du logiciel et, heureusement, vous disposez d'un outil puissant dans votre arsenal pour les résoudre : les critères d'acceptation.
Dans ce guide, je vais vous expliquer la nature de ce format d'expression des exigences, clarifier son rôle dans la gestion de produit, et vous montrer comment rédiger d’excellents critères d’acceptation.
Table des matières
Que sont les critères d’acceptation ?
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Quel est l’objectif de la rédaction des critères d’acceptation ?
À quoi doivent ressembler des critères d’acceptation bien rédigés ?
Formats courants de critères d’acceptation
Que sont les critères d’acceptation
(et quelle est leur place dans Agile/Scrum ?)
Dans la méthodologie Agile, un critère d’acceptation est la plus petite unité d’exigence fonctionnelle ou de conception que les chefs de produit Agile (ou les analystes métier) ajoutent à leurs histoires utilisateur pour communiquer clairement les différents états et comportements des fonctionnalités que l’équipe envisage de développer.
Techniquement, vous pouvez utiliser les critères d’acceptation où vous le souhaitez. Cependant, ils sont traditionnellement intégrés aux user stories, qui sont des composants des épopées Agile.
Pour mieux comprendre les critères d'acceptation, commençons par nous remémorer les éléments de cette hiérarchie et voyons à quoi sert chacun d’entre eux.
Épopées
Les épopées (ou "epics") sont des tâches qui regroupent les exigences fonctionnelles et non fonctionnelles de haut niveau d’une fonctionnalité majeure ou d’un ensemble de fonctionnalités liées entre elles. En général, une épopée couvre un cas d’utilisation complet pour vos clients et recense toutes les fonctionnalités et caractéristiques à mettre en œuvre afin de couvrir ce cas d’utilisation.
Imaginez que vous fassiez partie de l’équipe produit de Spotify et que vous vouliez élargir l’utilisation de l’application en ajoutant un nouveau cas d’usage pour les personnes qui sont en déplacement et sans accès à Internet.
Pour répondre à ce cas d'utilisation, vous pouvez envisager d'ajouter une grande nouvelle fonctionnalité intitulée « mode hors-ligne pour Spotify » ; elle peut devenir une épopée dans votre backlog produit et regrouper toutes les exigences générales pour permettre aux utilisateurs d’écouter leur musique sans connexion, ainsi que plusieurs user stories contenant les exigences pour les différentes parties de cette fonctionnalité.
User Stories
Les user stories sont de taille plus réduite et représentent une fonctionnalité spécifique et distincte au sein de l’épopée. Ce sont des tâches de petite taille auxquelles l’équipe Agile peut s’engager et livrer lors d’une seule itération.
Une caractéristique clé d’une user story est que la fonctionnalité qu’elle décrit doit être complète et potentiellement utilisable.
À titre d’exemple, si vous développez une application de stockage de fichiers en ligne et souhaitez permettre à vos utilisateurs de renommer les fichiers qu’ils ont téléchargés, il vous faudra intervenir à la fois sur le frontend (l’interface et l’expérience du renommage côté utilisateur) et sur le backend (l’enregistrement du nouveau nom).
Pour que la fonctionnalité soit complète et utilisable, vous devrez terminer ces deux tâches et relier les parties frontend et backend entre elles. Votre équipe accomplira tout cela dans le cadre d’une seule user story.
Si vous ne réalisez que la partie backend, la tâche qui en résulte ne constitue pas une story correcte car elle ne déboucherait pas sur un livrable complet et utilisable.
Pour indiquer à l’équipe de développement ce à quoi la fonctionnalité doit ressembler et comment elle doit se comporter, les product owners vont rédiger des critères d’acceptation associés à cette story.
Critères d’acceptation des user stories
Enfin, nous avons les éléments les plus petits de la hiérarchie des exigences produit logiciel : les critères d’acceptation. Ils représentent des scénarios d’utilisation individuels de cette fonctionnalité ou des éléments d’information que l’équipe technique doit connaître lors de la mise en œuvre de la story.
Dans l’exemple ci-dessus, un critère d’acceptation consisterait à ouvrir un champ de texte comportant le nom du fichier déjà renseigné si l'utilisateur clique sur le bouton ✏️Renommer d’un fichier qu’il a téléchargé.
Définition de terminé (et oui, c’est différent des critères d’acceptation !)
Il arrive parfois que les product owners (notamment ceux qui débutent dans ce rôle Scrum) confondent la définition de terminé avec les critères d’acceptation.
Pour être honnête, cela m’a moi-même un peu troublé au départ puisque les deux sont « des critères permettant de vérifier que la fonctionnalité est terminée ».
La seule différence est que la définition de terminé représente l'achèvement du point de vue des processus de développement de l’équipe.
Alors que les critères d’acceptation représentent les exigences fonctionnelles (à quoi la fonctionnalité doit ressembler et comment elle doit se comporter).
Cela signifie que la définition de terminé restera la même pour toutes les histoires que l'équipe met en œuvre, à moins qu'elle ne décide d’y apporter des modifications lors des rétrospectives. Les critères d’acceptation, au contraire, sont uniques à chaque histoire car ils expliquent la façon dont la fonctionnalité doit fonctionner.
Remarque : Certains outils de gestion de produit vous permettent d’inclure à la fois la définition de terminé et les critères d’acceptation dans vos histoires.
Maintenant que nous nous rappelons ce que sont les épopées et les histoires, et comment les critères d’acceptation s’y rapportent, passons à la compréhension de la raison pour laquelle les propriétaires de produit rédigent des critères d’acceptation en premier lieu.
Quel est l'objectif de rédiger des critères d’acceptation ?
Puis-je simplement écrire la description d’une user story comme je le souhaite sans y inclure de critères d’acceptation ? Quel est l’intérêt de rédiger des critères d’acceptation ?
Bien sûr, vous pouvez écrire vos histoires comme bon vous semble. Cependant, je vous recommande d’utiliser les critères d’acceptation comme une manière de formuler vos exigences, car ce format présente de nombreux avantages. En voici quelques-uns à considérer.
Ils favorisent une réflexion orientée comportement
Si vous optez pour le format BDD des critères d’acceptation (nous y reviendrons plus loin), alors vos critères d’acceptation décriront le parcours de vos utilisateurs lorsqu’ils utilisent la fonctionnalité en question.
La beauté de cette approche, c’est qu’elle vous permet de cesser de penser en termes d’exigences techniques sèches et de commencer à considérer la fonctionnalité du point de vue de l’utilisateur. Cela vous permet de visualiser ce que l’utilisateur ressent et vit lorsqu’il interagit avec votre fonctionnalité.
Il est très courant que le Product Owner se rende compte que la fonctionnalité qu'il avait imaginée n’est pas la meilleure une fois qu’il l’analyse du point de vue de ses utilisateurs.
J’ai moi-même rencontré ce cas à plusieurs reprises. Par exemple, lorsque je rédigeais les exigences pour un éditeur de formules mathématiques (cela faisait partie d’un produit SaaS d’analyse financière que nous développions à l’époque), je voulais que le processus d’édition ressemble à ceci :
- Un bouton d’édition à côté de la formule.
- Un clic sur le bouton d’édition rendrait le champ formule éditable et afficherait les boutons ✅ Sauvegarder et ❎ Annuler.
- Un clic sur l’un de ces boutons quitterait le mode édition et la nouvelle version enregistrée ou l’ancienne version de la formule s’afficherait selon le choix de l’utilisateur.
Ce comportement semble logique, non ?
Eh bien, pas avant d’avoir rédigé des scénarios d’utilisation par les analystes et découvert un important défaut d’ergonomie. Les analystes modifient généralement la formule en effectuant de petits ajustements et en observant le résultat du calcul jusqu’à obtenir la formule désirée.
La façon dont j’avais imaginé l’édition serait extrêmement agaçante pour mes utilisateurs cibles, car ils auraient à entrer et sortir du mode édition 20 à 30 fois de suite. Dès que j’ai réalisé cette erreur, j’ai rapidement modifié les critères d’acceptation et demandé à construire un éditeur de formules où l’on peut faire des modifications en temps réel.
Ils contribuent à créer une source unique de vérité
En tant que jeune chef de produit, ma plus grande difficulté était de communiquer les exigences produit aux personnes de différents métiers, voire à différentes équipes. Le problème était que chacun comprenait les exigences à sa manière, ce qui entraînait une incompréhension générale.
C’est alors qu’un chef de produit expérimenté m’a suggéré d’appliquer le concept de source unique de vérité en formulant mes exigences produit de façon très claire (c’est quelque chose que l’intelligence artificielle dans la collecte des exigences peut aider à faire), en les communiquant à tout le monde et en leur demandant de baser leur travail uniquement sur ce qui est écrit.
Cela a été un immense succès, car tout le monde avait la même compréhension du fonctionnement attendu de la fonctionnalité et, en cas de désaccord, ils se référaient au document d’exigences.
Les critères d'acceptation constituent un excellent moyen de créer une source unique de référence car ils décrivent la fonctionnalité de manière claire, facile à lire et à un haut niveau de détail (puisqu'ils doivent couvrir tous les principaux aspects de la fonctionnalité).
Ils améliorent la qualité des tests d’acceptation
Pour les ingénieurs logiciels, les critères d’acceptation servent de cahier des charges produit à suivre pour développer la fonctionnalité. Pour votre équipe qualité, en revanche, ils ont quelques avantages supplémentaires :
Ils aident à prioriser les cas de test. Si votre équipe de test logiciel dispose de nombreux cas de test pour cette fonctionnalité et qu'il n'y a pas assez de temps pour tous les examiner, elle commencera par prioriser et exécuter les scénarios de test correspondant aux critères d'acceptation, car ils décrivent les parcours utilisateurs les plus critiques.
Ils servent de liste de vérification d’acceptation. Ce point concerne aussi bien les équipes QA que les Product Owners qui doivent valider la fonctionnalité. Les critères d'acceptation, comme leur nom l'indique, servent de check-list pour décider du statut de réussite/échec de la fonctionnalité. Si un ou plusieurs critères d’acceptation ne sont pas remplis, l’équipe QA rouvrira le sujet et demandera à l’équipe d’ingénierie d’ajouter la fonctionnalité manquante.
En résumé, les critères d'acceptation sont des outils inestimables pour les Product Owners qui souhaitent correctement communiquer les exigences produit. Mais alors, comment rédiger de bons critères d’acceptation ? Je vais vous aider à ce sujet ci-dessous.
À quoi doivent ressembler de bons critères d’acceptation ?
La qualité des critères d’acceptation que vous rédigez aura un impact direct sur la qualité des fonctionnalités livrées par votre équipe. Avec une compréhension claire de ce qu’il faut construire et comment le tester, votre équipe réalisera la fonctionnalité telle que vous la concevez avec un minimum d’accrocs.
Pour exceller dans la rédaction de critères d’acceptation, vous devez prêter attention aux points suivants.
Clarté
Le péché n°1 d’un Product Owner est de rédiger des critères d’acceptation flous ou ambigus. Oubliez l’idée d’une compréhension partagée si chacun peut interpréter ce que vous avez écrit de différentes manières.
Pour constater à quel point cela fait la différence, laissez-moi vous donner un exemple.
Qu’avez-vous compris de cette phrase ? Pouvez-vous me dire comment le distributeur automatique utilisera le type de carte pour décider s’il doit authentifier l’utilisateur ou non ? Le DAB authentifiera-t-il l’utilisateur si tous ces critères sont réunis simultanément ou suffit-il d’en remplir un seul ?
Si vous donnez ce critère d’acceptation à vos ingénieurs, ils vous inonderont de questions et vous demanderont d’être plus précis dans vos exigences. Améliorons cela.
C’est tout de suite plus clair, n’est-ce pas ? Avec ces critères d’acceptation, nous avons aussi apporté toutes les réponses aux questions précédentes. Le distributeur doit prendre en charge le type de carte inséré par l’utilisateur et les trois critères doivent être remplis simultanément pour que l’authentification ait lieu.
Astuce de pro : Rendez vos critères d’acceptation SMART (spécifiques, mesurables, atteignables, pertinents, testables). Oui, j’ai modifié le dernier en « testable », car il s’agit d’une caractéristique importante de critères d’acceptation efficaces.
Lisibilité
Au-delà d’éviter le flou dans vos critères d’acceptation, il faut également les garder simples et éviter les termes jargonneux ou l’anglais trop complexe.
Je suis sûr que vous avez une équipe de superstars diplômées pouvant lire et comprendre facilement les mots et expressions les plus sophistiqués de la langue anglaise, mais il serait dommage d’utiliser leur énergie à décrypter vos textes.
Donc, au lieu de cela…
Dites ceci.
Je parie même que vous n’avez pas pris la peine de lire en entier le premier critère d’acceptation car vous ne vouliez pas perdre de temps ni d’énergie !
Couverture des cas
Le diable se cache dans les détails. Parfois, vous vous rendez compte que vous avez oublié un cas épineux dans votre fonctionnalité alors que vous êtes déjà très avancé dans la phase de développement et devez créer une tâche d'amélioration supplémentaire, voire tout recommencer.
Ça vous parle, n'est-ce pas ?
Plus vous prenez de cas en compte dans vos critères d’acceptation dès le départ, moins vous risquez de vous retrouver dans ce scénario avec vos éléments du backlog.
Voyons maintenant les critères d’acceptation ci-dessous.
Voyez-vous quelque chose d’inhabituel ici ? À première vue, l’exigence est claire : vous ajoutez l’adresse e-mail, vous envoyez et la personne obtient l’accès. En réalité, nous n’avons pas pris en compte de nombreux cas ici :
- Si l’adresse e-mail figure déjà dans la liste des utilisateurs ayant accès au document, il serait peut-être utile d’afficher un message d’erreur pour en informer l’utilisateur.
- Vous allez envoyer un e-mail d’invitation à l’utilisateur : il serait donc pertinent d’indiquer dans la liste s’il a accepté ou non l’invitation.
- S’il n’a pas accepté l’invitation, il pourrait être utile d’ajouter un bouton “Renvoyer l’invitation”.
Il existe aussi des cas « négatifs », c’est-à-dire lorsque vous clarifiez le comportement de votre fonctionnalité en cas de valeur vide, ou si une erreur survient.
Utilisation active de supports visuels
Les critères d’acceptation que j’ai partagés ci-dessus étaient-ils parfaitement clairs pour vous ? Lorsque j’ai parlé du champ “Ajouter des personnes et des groupes”, avez-vous compris de quoi il s’agissait ?
Parfois, les mots ne suffisent plus à apporter de la clarté sur les exigences à votre équipe et il vaut mieux leur montrer que leur dire. Permettez-moi maintenant d’améliorer un peu ces critères d’acceptation.
Puis-je supposer que vous auriez facilement compris ce dont je parlais à propos de ces critères d’acceptation si vous consultiez l’image et mes commentaires côte à côte ? Je parie que oui.
Voilà qui couvre les « critères d’acceptation » des critères d’acceptation—passons maintenant aux différents types et formats utilisés par les équipes produit.
Formats courants de critères d’acceptation
Je dois être honnête avec vous : j’utilise rarement le même format dans toutes mes user stories. En effet, différents formats de critères d’acceptation conviennent à des cas d’usage différents, et il n’est pas toujours pertinent de s’imposer systématiquement le même format.
Je choisis donc le format selon l’histoire et le type d’informations que je souhaite spécifier dans ses critères d’acceptation.
Voyons maintenant quelques formats courants et leurs exemples de critères d’acceptation correspondants.
Format BDD
BDD signifie Behavior-driven Development (développement piloté par le comportement) et c’est un cadre recommandant aux membres de l’équipe de développement logiciel et produit de définir les exigences à partir de la façon dont leurs utilisateurs interagiront avec la fonctionnalité.
Comme manière de rédiger les exigences selon le comportement utilisateur, les critères d’acceptation pour la BDD suivent ce modèle spécifique :
Étant donné : La précondition du scénario précis du comportement utilisateur.
Quand : L’action effectuée par l’utilisateur.
Alors : Le résultat de l’action.
Ainsi, si vous souhaitez expliquer le fonctionnement de la fonctionnalité de retrait d’un distributeur automatique, vos critères d’acceptation ressembleraient à ça :
Le format donné/quand/alors est idéal lorsque vous souhaitez susciter de l’empathie pour les besoins utilisateurs au sein de votre équipe, en mettant l’accent sur le point de vue de l’utilisateur.
Format Checklist
Contrairement au BDD (également appelé format « orienté scénario »), celui-ci ne met pas en avant le point de vue de l’utilisateur final. Il s’agit plutôt d’exposer les règles que doit respecter la logique métier de la fonctionnalité (le nom alternatif de ce format est « orienté règles »). Voici à quoi cela ressemble :
Ce format est idéal si la logique à expliquer est complexe car il vous permet de la diviser en plusieurs règles simples, plus faciles à comprendre et à mettre en œuvre.
Format Flow
C'est probablement le format que j'utilise le plus.
Le format déroulé est similaire au format BDD car il présente également le point de vue de l'utilisateur. Cependant, contrairement à la BDD, il n'impose pas une structure stricte (Given/When/Then). Vous êtes donc libre de raconter les étapes réalisées par l'utilisateur comme vous le souhaitez.
Voici à quoi le processus d'inscription ressemblerait avec ce format.
Le format déroulé sera votre meilleure option si vous souhaitez créer de l'empathie utilisateur (comme avec la BDD) mais que vous ne voulez pas vraiment suivre une structure stricte.
Gardez tout le monde aligné grâce aux critères d’acceptation
Les critères d’acceptation sont des outils puissants entre les mains des responsables produit, leur permettant de créer une source unique de vérité et d’aligner leurs coéquipiers sur leur vision pour cette fonctionnalité.
Pour plus de guides comme celui-ci, et d’autres ressources utiles aux produits, abonnez-vous à notre newsletter !
