Rédiger des critères d'acceptation qui tranchent vraiment le débat
Une user story n'est qu'un point de départ pour une conversation, et les critères d'acceptation sont l'endroit où cette conversation se fixe noir sur blanc. Ils énoncent les conditions qu'un élément du Product Backlog doit remplir avant que l'on s'accorde à le déclarer terminé. Sans eux, la notion de « terminé » dérive : le développeur croit que la fonctionnalité marche, le Product Owner attendait autre chose, et le désaccord éclate à la Sprint Review, au moment où il coûte le plus cher à corriger.
Avec des équipes désormais distribuées et hybrides après une longue période de télétravail, on ne peut plus compter sur une discussion improvisée dans le couloir pour lever une ambiguïté. La story et ses critères doivent porter le sens à eux seuls. Bien les rédiger est l'un des investissements qualité les moins coûteux qu'une équipe puisse faire.
À quoi ressemblent de bons critères d'acceptation
Les critères d'acceptation ne sont ni un document de conception, ni des scripts de test. Ils décrivent des résultats observables du point de vue de l'utilisateur, pas l'implémentation. Ils ne se confondent pas non plus avec la Definition of Done, une confusion qu'il vaut mieux dissiper tôt : la Definition of Done est une norme commune qui s'applique à chaque élément du Product Backlog, tandis que les critères d'acceptation sont propres à une seule story. Mélangez les deux et vous alourdissez chaque story de formules toutes faites, ou vous laissez discrètement filer les exigences de qualité. Un bon ensemble de critères est :
Vérifiable — on peut dire clairement réussi ou échoué, sans interprétation
Axé sur le résultat — ce que l'utilisateur peut désormais faire, pas comment le code le fait
Indépendant — chaque critère se tient seul
Sans détail de solution — laissez le « comment » aux Développeurs
Peu nombreux — de trois à sept points, pas une spécification
Un format lisible et répandu est Étant donné–Quand–Alors : étant donné un contexte, quand une action survient, alors un résultat précis s'ensuit. Ce n'est pas obligatoire — une simple liste de vérification fonctionne aussi — mais il vous force à nommer la condition préalable, le déclencheur et le résultat attendu.
Une manière pratique de les rédiger
Partez de l'objectif de l'utilisateur. Reformulez ce que la personne cherche à accomplir avant de lister la moindre condition. Si vous ne pouvez pas nommer l'objectif, la story n'est pas prête.
Décrivez d'abord le chemin nominal. Rédigez les critères du cas normal et réussi. C'est la colonne vertébrale sur laquelle tout le monde s'entend.
Ajoutez ensuite les cas limites qui comptent. Entrées vides, valeur maximale autorisée, session expirée, paiement refusé. N'incluez que les cas limites qui modifient le comportement, pas tous ceux qui sont théoriques.
Rendez chaque critère vérifiable. Remplacez « rapide », « convivial » ou « sécurisé » par quelque chose de contrôlable : un chiffre, un état visible, un message précis.
Validez-les avec l'équipe, pas seulement avec le Product Owner. Les développeurs et les testeurs repéreront des cas manquants et des hypothèses cachées avant le début du travail.
Gardez-les distincts de la Definition of Done. Les critères sont propres à cette story; la Definition of Done s'applique à chaque élément et couvre des aspects comme les tests qui passent et le code revu.
Erreurs courantes à éviter
Trois pièges reviennent sans cesse. Le premier consiste à y glisser la conception : « ajouter une liste déroulante » est une solution, tandis que « l'utilisateur peut choisir parmi les régions approuvées » est un résultat. Le deuxième, ce sont des critères si vagues qu'ils ne peuvent pas échouer, comme « fonctionne correctement ». Le troisième, c'est laisser la liste enfler en une mini-spécification de vingt points; c'est le signe que la story devrait être découpée. Il existe aussi un échec plus discret : rédiger les critères une fois et ne plus jamais y revenir, même quand la conversation durant le Sprint change ce que l'équipe a appris. Considérez-les comme vivants jusqu'à ce que l'élément soit terminé.
Quand les critères d'acceptation sont clairs, la Sprint Review cesse d'être une négociation pour devenir une démonstration, et la prévision de l'équipe se stabilise puisque chacun estime la même chose. Ils facilitent aussi grandement le découpage d'une grande story en tranches plus petites, chacune ayant sa propre valeur, car les critères révèlent les lignes de coupe naturelles. Y consacrer dix minutes avant de commencer fait régulièrement économiser des heures de reprise et les frictions qui l'accompagnent.
Si vos stories déclenchent encore des disputes « ce n'est pas ce que je voulais » au moment de la revue, le conseil en réalisation de programmes et de projets de XNM peut aider vos équipes à rédiger des critères solides et à resserrer le chemin du backlog au logiciel fonctionnel.