Une user story dit quoi et *pourquoi*. Les critères d'acceptation disent à quelles conditions elle sera considérée comme faite. Sans eux, « terminé » se discute sans fin.

À quoi ils servent

• Ils cadrent le périmètre exact de la story (ce qui est inclus, ce qui ne l'est pas).
• Ils donnent à l'équipe la cible précise à atteindre.
• Ils fournissent la base des tests.
• Ils évitent le désaccord à la revue : « ce n'est pas ce que je voulais ».

Comment les formuler

En phrases courtes et vérifiables, du point de vue de l'utilisateur. Un format répandu : « Étant donné [situation], quand [action], alors [résultat attendu] ». Mais une simple liste à puces claire fait l'affaire.

Exemple pour la story « voir mon solde de points »

• Le solde s'affiche sur l'écran d'accueil, en haut, visible sans défiler.
• Le solde est à jour à la seconde près après un achat.
• Si le solde est de zéro, l'écran affiche « 0 point » et non un espace vide.
• Un solde supérieur à 9 999 s'affiche avec un séparateur de milliers.

Qui les écrit, et quand

Le PO les propose, l'équipe les challenge et les complète, avant que la story n'entre en sprint. Une story sans critères d'acceptation n'est pas prête (voir la Definition of Ready, au chapitre suivant).

Le bon nombre

Assez pour lever les ambiguïtés, pas au point de re-spécifier chaque détail. Trois à sept critères pour une story courante.

Exemple concret : à l'affinage, l'équipe de fidélité découvre en écrivant les critères que personne n'avait pensé au cas « solde à zéro ». La discussion a lieu avant le développement, pas à la revue.

À vous de jouer : pour une story de votre choix, écrivez deux critères d'acceptation vérifiables.