Critères d'acceptation sur une user story : les erreurs que les équipes font le plus souvent
Les critères d'acceptation définissent les conditions dans lesquelles un élément du Product Backlog est considéré terminé par le Product Owner. C'est le contrat entre le Product Owner et l'équipe de développement pour un élément spécifique.
Les erreurs
Erreur 1 : Trop vague pour être testable. "Fonctionne correctement" n'est pas un critère d'acceptation. "L'utilisateur reçoit un e-mail de confirmation dans les 60 secondes suivant la soumission du formulaire" l'est. Les critères doivent être suffisamment précis pour qu'un jugement binaire puisse être formulé.
Erreur 2 : Rédigés après le début du développement. Lorsque les critères sont rédigés après que le développement a commencé, ils décrivent ce qui a été construit plutôt que ce qui était nécessaire. Solution : les critères doivent être examinés et convenus par l'équipe avant la fin du Sprint Planning.
Erreur 3 : Testables mais pas du point de vue de l'utilisateur. "L'API renvoie un code de statut 200" est testable ; c'est aussi inutile comme critère d'acceptation sauf si la réponse est la valeur que l'utilisateur reçoit.
Erreur 4 : Cas limites et états d'erreur manquants. Les critères du chemin heureux décrivent ce qui se passe quand tout fonctionne. La plupart des défauts surviennent dans les cas limites : que se passe-t-il quand le réseau est lent, quand un champ est vide ?
Erreur 5 : Non examinés par l'équipe de développement avant le début du Sprint. Les critères que l'équipe n'a pas lus avant la fin du Sprint Planning généreront des surprises pendant le Sprint.
XNM accompagne les organisations dans la mise en place de pratiques Scrum efficaces. Contactez l'équipe de conseil en livraison de programmes et de projets de XNM pour du soutien dans votre livraison agile.