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 : ils précisent les formats acceptables, fournissent des exemples concrets et indiquent 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 — 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, pas 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 vous retrouverez avec une fonctionnalité livrée sur laquelle personne ne s’était 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 élément que vous pourriez confier à un testeur n’ayant jamais assisté à votre réunion de raffinement, 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 une affirmation ne peut pas être vérifiée — « la page est intuitive », « les performances sont bonnes » —, ce n’est pas un critère, mais un vœu pieux. Supprimez-la ou rendez-la 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 ».

Si / Quand / 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 qu’un critère vague omet justement de préciser.

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 valides, 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 intitulé « Filtrer le 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 — il n’y a pas de 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 jeu 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 qu’un 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, après coup.
  • 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 concerne 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 histoire 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 histoires qui se font passer pour 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 sur ces critères qu’elle est divisée. La liste est alors 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 représente une petite partie que l’équipe pourrait livrer, présenter lors d’une démonstration, puis laisser de côté. Considérer l’ensemble de la liste 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 procéder à cette ventilation, examinez chaque critère et posez-vous la question que vous poseriez pour n’importe quelle user story : l’équipe serait-elle prête à livrer cet élément de manière isolée ? L’utilisateur en tirerait-il un bénéfice s’il était livré seul ? Serait-il possible d’en faire une démonstration ? Les points qui résistent à cette interrogation 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 de la portée d’une « user story » que vous avez déjà isolée, et non d’un travail autonome.

C’est lorsque les critères sont étroitement liés que cela ne fonctionne pas — « 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 mal conçu que personne ne le mène à son terme. « 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 le périmètre du travail ; les critères en garantissent 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 scénario et critères d’acceptation

Les critères d’acceptation décrivent le résultat attendu — ce qui doit être vérifié pour que l’itération soit considérée comme livrée. Les points d’histoire décrivent le chemin à parcourir — l’ampleur du travail à accomplir entre « nous n’en sommes pas encore là » 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 avoir cet effet. 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’en est pas un — 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 — 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 rempli, soit non rempli.

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’a jamais vu cette story. Utilisez la structure « Given/When/Then » pour les comportements qui dépendent d’un état, ou une simple liste de vérification pour un ensemble d’exigences indépendantes. Veillez à ce qu’elles soient testables, concentrez-vous sur les résultats, et ne dépassez pas environ cinq éléments — au-delà, vous vous retrouvez 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 satisfaire à 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 l’objectif ; 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