Critères d'acceptation : comment les rédiger

Les critères d'acceptation constituent le test de réussite ou d'échec d'une story, rédigés avant le début des travaux : les formats valides, des exemples concrets et en quoi ils diffèrent de la définition de « terminé ».

Les critères d’acceptation sont les conditions qu’une story doit remplir pour être acceptée : il s’agit d’un test de type « réussi/échoué », rédigé avant que quiconque ne commence à coder. Il n’y a pas de « note partielle » : soit toutes les conditions sont remplies, soit elles ne le sont pas. Ils décrivent ce que le résultat doit faire, et non la manière de le réaliser. Et il s’agit d’un test, et non d’une deuxième description de la fonctionnalité. Si vous pouvez les satisfaire avec un code qui ne résout pas le problème, ce ne sont pas des critères d’acceptation ; ce sont des exigences déguisées.

Chaque projet soulève une question implicite : comment saurons-nous qu’il est terminé ? Les critères d’acceptation y répondent clairement, avant même que le travail ne commence. Si vous les définissez correctement, l’estimation devient plus facile, la démonstration s’écrit d’elle-même et la notion de « terminé » cesse d’être un sujet de négociation. Si vous les laissez vagues, vous livrerez une fonctionnalité sur laquelle personne ne s’est mis d’accord.

Ce que sont les critères d’acceptation, et ce qu’ils ne sont pas

Un bon critère d’acceptation est un critère que vous pourriez confier à un testeur n’ayant jamais assisté à votre réunion de refinement, et qui saurait exactement ce qu’il doit vérifier. Il décrit un résultat que l’utilisateur peut observer, et non la mise en œuvre qui le produit. « Utiliser un cache Redis » n’est pas un critère d’acceptation ; c’est une solution. « Les résultats s’affichent en moins d’une seconde pour un tableau de 10 000 lignes », en revanche, en est un, car n’importe qui peut le tester sans avoir à lire le code pour ce faire.

Il ne s’agit pas non plus d’une liste de souhaits. Chaque critère doit pouvoir être réfuté. Si un élément ne peut pas être vérifié (« la page est intuitive », « les performances sont bonnes »), ce n’est pas un critère, mais un espoir. Supprimez-le ou rendez-le mesurable.

Les deux formats qui fonctionnent

Utilisez la méthode Given/When/Then pour les comportements qui dépendent d’un état, et une simple liste de contrôle pour un ensemble d’exigences indépendantes. La plupart des équipes ont tendance à recourir systématiquement à la méthode Given/When/Then pour tout ; évitez de tomber dans ce piège. Une liste de contrôle est plus rapide à lire et plus difficile à gonfler artificiellement lorsque l’exigence se résume à « ces cinq éléments doivent être vérifiés ».

Étant donné que / Lorsque / Alors

Partant d’un état initial, lorsque l’utilisateur effectue une action, le système réagit alors d’une manière spécifique. Ce format fait ses preuves en vous obligeant à nommer ces trois éléments (la condition préalable, le déclencheur et le résultat observable), ce qui est précisément ce qu’un critère vague omet.

Exemples de critères d’acceptation

Une histoire de connexion, rédigée selon le modèle « Given/When/Then » :

  • Si un utilisateur enregistré se trouve sur la page de connexion, **lorsqu’**il saisit une adresse e-mail et un mot de passe corrects, alors il accède à son tableau de bord.
  • Si un utilisateur enregistré saisit trois fois un mot de passe erroné, alors son compte est verrouillé pendant 15 minutes et il peut voir le temps qu’il lui reste.
  • Si, sur la page de connexion, lorsque le champ « e-mail » est vide, alors le bouton « Valider » est désactivé.

Un article sur le « filtrage du tableau des résultats », présenté sous forme de liste de contrôle :

  • Le filtre s’applique dès que vous effectuez une sélection, sans qu’il soit nécessaire d’appuyer sur un bouton « Appliquer » distinct.
  • Deux filtres sont combinés avec l’opérateur « ET », et non avec l’opérateur « OU ».
  • La suppression de tous les filtres permet de rétablir la liste complète, non triée.
  • Un ensemble de résultats vide indique l’état « aucune correspondance », et non un tableau vide.

Remarquez ce que ces deux éléments omettent : la base de données, le framework, les noms des composants. Ils indiquent ce que l’utilisateur obtient, et non la manière dont vous allez le lui fournir. Et chaque ligne correspond à un élément que le testeur peut valider ou rejeter sans avoir à vous poser de question.

Comment rédiger des critères d’acceptation

  • Rédigez-les pendant la précision du backlog, avec l’équipe, et non pas seul par la suite.
  • Un résultat observable par ligne. Si une ligne contient un « et » qui a une réelle incidence, cela correspond à deux critères.
  • Identifiez les cas de figure indésirables. L’état vide, le délai d’expiration, une entrée erronée : c’est là que se cache le plus gros de l’effort.
  • Veillez à ce qu’ils portent sur le comportement, et non sur la conception. La maquette traite de la mise en page ; les critères définissent ce qui doit être respecté.
  • Arrêtez-vous vers cinq heures.

À partir de combien de critères d’acceptation peut-on considérer qu’il y en a trop ?

Environ cinq. Non pas parce qu’il existe une règle, mais parce qu’une story qui nécessite dix conditions distinctes et vérifiables comporte dix éléments de valeur distincts, ce qui signifie qu’il s’agit en réalité de plusieurs stories présentées comme une seule. Lorsque la liste s’allonge, ce sont les critères d’acceptation qui constituent la base de la division.

Segmentation selon les critères d’acceptation

Si une tâche comporte plus de cinq critères d’acceptation, c’est généralement à partir de ces critères qu’on la décompose. La liste est un backlog qui fait office de liste de contrôle.

Les critères d’acceptation servent à décrire une story. Ils ne sont pas censés constituer la story elle-même. Lorsque la liste s’allonge (six, huit, dix points), l’équipe a souvent procédé à ce fractionnement sans s’en rendre compte. Chaque critère correspond à une petite partie que l’équipe pourrait livrer, présenter en démonstration, puis laisser de côté. Considérer la liste dans son ensemble comme un engagement unique oblige l’équipe à tout prendre en charge d’un seul coup, ce qui constitue la pire combinaison de volume et de risque que l’on puisse confier à quelqu’un au cours d’un sprint.

Pour les distinguer, prenez chaque critère et posez-vous la question que vous poseriez pour n’importe quelle user story : l’équipe serait-elle prête à livrer cela de manière autonome ? L’utilisateur en tirerait-il un bénéfice en soi ? Serait-il possible d’en faire une démonstration ? Les points qui résistent à cette question constituent des user stories. Les points qui ne satisfont pas à ce critère appartiennent généralement à l’une des « user stories » retenues : il s’agit d’éléments relevant du périmètre d’une « user story » que vous avez déjà isolée, et non d’un travail autonome.

C’est sur les critères étroitement liés que cela pose problème : « le formulaire valide les données saisies et les enregistre dans la base de données et affiche une confirmation ». Ces trois éléments semblent pouvoir être séparés, mais l’utilisateur n’en tire aucun bénéfice si un seul d’entre eux est mis en œuvre. Il ne s’agit pas d’une séparation par critère ; c’est une seule et même petite story, et les puces ne font que refléter la rigueur de l’équipe.

Critères d’acceptation et exigences

Une exigence définit ce qu’il faut développer. Un critère d’acceptation définit comment vous saurez que vous avez développé ce qu’il fallait. « Les utilisateurs peuvent réinitialiser leur mot de passe » est une exigence, et vous pouvez y répondre avec un processus si défaillant que personne ne parvient à le mener à bien. « Un utilisateur qui demande une réinitialisation reçoit un e-mail dans les deux minutes, dont le lien expire au bout d’une heure » est un critère d’acceptation, car il s’agit d’un test auquel le processus défaillant échoue. Les exigences définissent la portée du travail ; les critères en déterminent la validité.

Critères d’acceptation et définition de « terminé »

Ces deux notions sont constamment confondues, alors que la distinction est simple : les critères d’acceptation s’appliquent par story ; la définition de « terminé » est globale. Les critères ci-dessus décrivent ce que la story « connexion » doit spécifiquement faire. La définition de « terminé » (testé, révisé, documenté, déployé en environnement de préproduction) s’applique à chaque story que l’équipe livre. Une story peut satisfaire à ses critères d’acceptation sans pour autant être considérée comme terminée, car « fonctionne comme spécifié » et « prêt à être mis en production » sont deux niveaux d’exigence différents. Les deux sont indispensables.

Points de story vs critères d’acceptation

Les critères d’acceptation décrivent le résultat : ce qui doit être vérifié pour que l’histoire soit considérée comme livrée. Les points d’histoire décrivent le chemin à parcourir : l’ampleur du travail à accomplir entre « nous ne disposons pas encore de cela » et « les critères sont satisfaits ». Il s’agit de deux axes distincts. Les confondre conduit soit à des critères chiffrés, ce qui n’a aucun sens, soit à des estimations en points sans critères sous-jacents, ce qui relève du vœu pieux.

L’ajout d’un critère modifie-t-il l’estimation ? Parfois. Un critère qui met en évidence un travail caché (« doit être accessible aux lecteurs d’écran ») a généralement cet effet, car il nomme un effort qui était implicite. Un critère qui se contente de clarifier une hypothèse existante (« doit fonctionner sur Chrome et Safari », alors que ces navigateurs ont toujours été pris en charge) ne devrait pas l’avoir. L’ordre est important : les critères d’abord, puis les points. Estimer avant que les critères ne soient clairs revient à estimer avant le raffinement, et c’est la cause la plus fréquente de votes très dispersés.

Rédigez le test avant de commencer le travail. Si un critère ne peut pas échouer, ce n’est pas un critère. Et si vous en avez plus de cinq, vous avez probablement plus d’une histoire.

Foire aux questions

Que sont les critères d’acceptation ?

Les critères d’acceptation sont les conditions qu’une story doit remplir pour être acceptée : il s’agit d’un test de type « réussi/échoué » défini avant le début des travaux. Ils décrivent ce que le résultat doit faire, et non la manière de le réaliser, et il n’y a pas de notation partielle : chaque critère est soit respecté, soit non respecté.

Comment rédige-t-on des critères d’acceptation ?

Rédigez chacune d’entre elles comme si vous deviez la remettre à un testeur qui n’aurait jamais vu cette story. Utilisez la structure « Given/When/Then » pour les comportements qui dépendent d’un état, ou une simple liste de contrôle pour un ensemble d’exigences indépendantes. Veillez à ce qu’elles soient testables, concentrez-vous sur les résultats, et limitez-vous à environ cinq. Au-delà, vous vous retrouverez face à plusieurs stories.

Quelle est la différence entre les critères d’acceptation et les exigences ?

Les exigences indiquent ce qu’il faut développer ; les critères d’acceptation précisent comment vous saurez si le résultat est correct. Une exigence peut être satisfaite par un code qui passe à côté de l’essentiel. Un critère d’acceptation est un test : s’il est réussi, cette partie de l’histoire est terminée ; si vous parvenez à le réussir sans résoudre le problème de l’utilisateur, il s’agit en réalité d’une exigence déguisée.

Quelle est la différence entre les critères d’acceptation et la définition de « terminé » ?

Les critères d’acceptation s’appliquent à chaque story : ils décrivent ce que cette story particulière doit permettre de réaliser. La définition de « terminé » correspond à une liste de contrôle globale qui s’applique à toutes les stories (testée, révisée, documentée, déployée). Une story peut remplir ses critères d’acceptation sans pour autant être considérée comme terminée si elle ne franchit pas l’étape de validation par l’ensemble de l’équipe.

Qui rédige les critères d’acceptation ?

C’est le Product Owner qui en est responsable, mais ils sont rédigés en collaboration avec l’équipe lors de la phase d’affinage. Le Product Owner définit le résultat attendu ; les développeurs et les testeurs mettent en évidence les cas limites. Les critères d’acceptation rédigés isolément, a posteriori, sont ceux qui ne prennent pas en compte le cas qui provoque une défaillance en production.

Lectures complémentaires