L'histoire que tout le monde a approuvée et que personne ne pouvait tester
Pendant la planification de Sprint, une équipe Scrum a pris une histoire qui disait simplement : « Les utilisateurs peuvent réinitialiser leur mot de passe. » Tout le monde a hoché la tête. Le Product Owner était content, les développeurs l'ont estimée, et elle est entrée dans le Backlog de Sprint. Trois jours plus tard, elle était « terminée » — et aussitôt contestée. Le Product Owner attendait un lien par courriel avec une expiration ; les développeurs avaient construit un parcours par question de sécurité. Les deux étaient des lectures défendables d'une phrase floue. C'est une situation anonymisée mais très ordinaire, et la cause profonde est presque toujours la même : l'élément n'avait pas de critères d'acceptation.
Ce que sont vraiment les critères d'acceptation
Les critères d'acceptation sont les conditions précises et testables qu'un élément du Backlog produit doit satisfaire pour être considéré comme terminé par le Product Owner. Ce ne sont pas la Définition de Terminé — le Guide Scrum décrit la Définition de Terminé comme la norme de qualité partagée appliquée à chaque Incrément (tests réussis, code revu, déployable). Les critères d'acceptation sont propres à un élément : ils décrivent ce que cette histoire-là, précisément, doit faire. Une équipe a besoin des deux. « Terminé » est la barre que chaque élément franchit ; les critères d'acceptation indiquent si cet élément a fait la bonne chose.
Réécrire l'histoire du mot de passe avec des critères change tout :
Étant donné qu'un utilisateur inscrit demande une réinitialisation, quand il soumet son courriel, alors un lien de réinitialisation est envoyé à cette adresse.
Le lien de réinitialisation expire 30 minutes après son émission.
Un lien expiré ou déjà utilisé affiche un message clair et propose de le renvoyer.
Après une réinitialisation réussie, l'ancien mot de passe de l'utilisateur ne fonctionne plus.
Il n'y a désormais plus rien à débattre à la fin du Sprint. La conversation qui aurait été une dispute tendue autour d'une version terminée a eu lieu plutôt pendant le raffinement, à moindre coût, avant qu'une seule ligne de code ne soit écrite.
Des habitudes qui gardent les critères utiles
Les écrire avant que l'élément soit prêt pour le sprint. Les critères d'acceptation relèvent du raffinement du Backlog produit, pas de la démonstration. Une histoire sans eux n'est pas prête à être planifiée.
Rendre chaque critère testable. Si vous ne pouvez pas imaginer la vérification qui le prouve vrai ou faux, c'est un souhait, pas un critère. « Rapide » est un souhait ; « répond en moins de deux secondes » est un critère.
Les centrer sur les résultats, pas sur la mise en œuvre. Énoncez ce que l'utilisateur doit pouvoir faire, et laissez aux développeurs la marge de décider comment. Les critères contraignent le résultat, pas la conception.
Garder l'ensemble petit. Trois à six conditions nettes valent mieux que quinze floues. Si une histoire a besoin d'une douzaine de critères, ce sont probablement deux histoires.
Pourquoi cela compte davantage dans une équipe dispersée
Quand tout le monde partageait une salle, une histoire à moitié définie pouvait survivre grâce à de rapides questions de clarification d'un bureau à l'autre. Avec des équipes à distance, ce canal de réparation informel est plus faible et plus lent. Des critères d'acceptation écrits et testables portent la compréhension partagée que les conversations de couloir assuraient autrefois. Ce n'est pas de la bureaucratie — c'est l'assurance la moins chère dont dispose une équipe Scrum contre le fait de bien construire la mauvaise chose.
Si vos équipes terminent sans cesse un travail qui rate l'intention, le conseil en réalisation de programmes et de projets de XNM peut vous aider à resserrer la façon dont vous définissez et acceptez le travail.