U2 · Écrire des critères d'acceptation testables · Lecture · 18 min
Une story sans critères d'acceptation n'est pas terminée. Elle exprime une intention ; elle ne dit pas à quel moment on aura le droit de la considérer comme faite. C'est cette absence qui produit les fins de projet interminables, où le client trouve toujours qu'il manque quelque chose et où le prestataire ne peut pas démontrer le contraire.
Étant donné [contexte], quand [action], alors [résultat observable].
Exemple : Étant donné une demande au statut Nouveau depuis plus de trois jours, quand Sophie ouvre sa vue du matin, alors cette demande apparaît en tête de liste.
Les trois parties comptent. Le contexte pose la situation de départ, sans laquelle le critère est ambigu. L'action est un geste précis. Le résultat est ce qu'on constate.
Un critère est bon quand quelqu'un qui n'a pas participé au projet peut le vérifier seul, en suivant la phrase à la lettre. C'est le seul test qui vaille.
À l'inverse, voici ce qui n'est pas observable, et qu'on écrit pourtant tout le temps : « c'est rapide », « c'est intuitif », « ça marche bien », « l'utilisateur comprend facilement ». Ces formules ne se vérifient pas, donc elles ne se contestent pas — et donc elles ne protègent personne.
Les critères ne servent pas seulement à cadrer ce qui doit marcher. Ils délimitent aussi ce que tu ne fais pas — et à ce titre, ils sont ton meilleur outil de négociation en fin de projet.
Écrire « le client accède à sa page en lecture et en commentaire, sans possibilité de modification » ferme la porte à la demande qui arrivera immanquablement en semaine six : « ce serait bien qu'il puisse valider directement ». Cette demande deviendra alors une évolution discutée, et non un dû implicite.
De deux à cinq par story. Un seul critère signale presque toujours une story trop vague pour être cadrée. Au-delà de cinq, c'est la story qui est trop grosse : découpe-la, les critères se répartiront d'eux-mêmes.