Les critères d’acceptation, c’est un peu le contrat entre « ce que j’imagine » et « ce que je vais recevoir ». Sans eux, ton ticket est une lettre au Père Noël : tout le monde y met ce qu’il veut.
Le concept en bref
Ce format aide à définir précisément ce qu’une fonctionnalité doit faire, du point de vue de l’utilisateur final, avant qu’elle ne soit développée.
Une story, c’est avant tout une amorce à la discussion. Les critères d’acceptation sont ce qui transforme cette discussion en un accord partagé : ils décrivent comment la fonctionnalité doit se comporter, y compris dans ses scénarios négatifs (unhappy flow).
Pourquoi c’est important
- Moteur de communication et de réflexion — ils déclenchent la réflexion de l’équipe sur le comportement attendu, vu du côté utilisateur (persona)
- Base des cas de test — l’équipe écrit des tests précis, cohérents sur toute la vie du ticket, scénarios négatifs inclus
- Clarification du scope — ils posent les limites du ticket et réduisent les ambiguïtés
- Garantie d’alignement — toutes les parties prenantes partagent la même compréhension de ce qui sera livré
- Aide à l’estimation — en précisant ce qui doit être développé, ils facilitent le découpage en tâches (et parfois en sous-stories)
Comment faire
Qui rédige ? Le PO reste responsable, mais délègue naturellement selon les compétences disponibles dans l’équipe :
- les analystes qui connaissent le sujet du ticket
- le métier, qui s’assure que le besoin exprimé sera bien couvert
- le développeur, qui confirme sa compréhension du ticket
- le QA, qui traque l’incohérence ou l’angle mort
Le plus efficace est souvent un mélange de ces regards croisés plutôt qu’une rédaction en solo.
Quand ? Le plus tôt possible et à plusieurs moments : à la rédaction de la demande métier, durant une phase de discovery ou d’analyse, durant les exercices d’affinage du backlog, et en tout cas avant le développement.
Sous quel format?
- La check-list — simple liste de critères à cocher
- Le(s) scénario(s) — structure Étant donné / Lorsque / Alors, éventuellement formalisée en Gherkin
Rien n’empêche l’équipe d’inventer son propre format, tant qu’il reste partagé et compris par tous.
Exemple concret
Consulter la fiche d’un livre sur un site d’e-commerce
En tant que client du site, je souhaite chercher un livre par auteur, titre ou ISBN afin de consulter sa fiche.
Liste :
- Résultat unique → j’accède directement à la fiche du livre
- Aucun résultat → je suis invité à relancer une recherche
- Plusieurs résultats → je choisis parmi une liste
Scénario (un seul résultat) : Étant donné que je suis sur la page de recherche Lorsque je saisis un critère de recherche et qu’il n’y a qu’un résultat Alors j’accède directement à la fiche du livre
Pièges & limites
Utiliser le « je » dans les critères aide à se mettre à la place de l’utilisateur et à garder ses besoins au centre — plutôt qu’une formulation impersonnelle et technique.
Attention à ne pas transformer les critères d’acceptation en spécification technique exhaustive : ils décrivent un comportement attendu, pas une implémentation.