Les critères d’acceptation : le maillon (trop) souvent oublié des User Stories

Parmi les erreurs les plus fréquentes dans la rédaction des User Stories, la négligence des critères d’acceptation figure en tête de liste. Pourtant, ces derniers sont essentiels pour garantir une compréhension partagée entre les développeurs, les testeurs et le Product Owner. Et surtout, ils conditionnent la validation fonctionnelle du livrable.

Un constat alarmant : 86 % des US n’ont pas de critères d’acceptation

Lors de nos interventions, nous avons constaté que 86 % des User Stories analysées ne contenaient aucun critère d’acceptation. Elles se limitaient à une simple description, parfois agrémentée de commentaires issus d’échanges informels.

La première question est simple : comment l’équipe valide-t-elle l’US ? Sur quelles bases s’appuie-t-on pour dire « c’est fait » ou « c’est conforme aux attentes » ?

Ce que doit contenir une User Story de qualité

Une User Story bien rédigée doit impérativement inclure deux éléments :

1. Une description claire, compréhensible par l’ensemble de l’équipe (et pas seulement par les développeurs).
2. Des critères d’acceptation, formulés de manière fonctionnelle, décrivant ce que le système doit faire (et ne pas faire).

Attention : les critères d’acceptation ne sont pas des tests d’acceptance. Ce sont des conditions de validation fonctionnelles, pas des cas de test détaillés ni des instructions techniques.

Pourquoi les critères d’acceptation sont essentiels ?

Les critères d’acceptation jouent un rôle central dans la qualité logicielle :

• Pour les développeurs, ils clarifient les objectifs de l’US et réduisent les zones d’ombre.
• Pour les testeurs, ils permettent d’identifier les éléments à tester, les comportements attendus, les cas limites…
• Pour le Product Owner, ils sécurisent la validation du périmètre fonctionnel.

En somme, ils favorisent un alignement clair des attentes.

Bonnes pratiques pour rédiger des critères d’acceptation efficaces

Voici quelques conseils concrets pour améliorer la qualité de vos critères d’acceptation :

• Formulez-les en termes de comportements attendus, en vous posant la question : que doit faire le système dans ce cas précis ?
• Décrivez également ce qu’il ne doit pas se produire, comportements interdits, messages d’erreur, accès restreints…
• Évitez les instructions techniques : les critères d’acceptation ne sont pas une notice pour les développeurs.
• Limitez-vous à 6 à 9 critères maximum par US. Au-delà, c’est souvent le signe que votre User Story est trop complexe.
• Plus de 10 critères ? Scindez votre US en plusieurs stories plus simples et mieux ciblées.

Et vous, avez-vous déterminé des critères d’acceptation à vos US ?

La réalisation d’un audit de maturité avec SSID vous permet d’avoir une vision claire de votre projet et de déterminer vos axes d’amélioration pour atteindre vos objectifs. SSID vous accompagne également dans la réalisation d’un plan d’action afin de mettre en place nos préconisations efficacement dans votre équipe. Alors, on s’appelle ?

Cet article fait référence à un webinaire sur « les 10 commandements pour livrer de la non-qualité en production ». À retrouver en replay sur notre chaîne YouTube.

Retrouvez les autres commandements sur notre blog :

1. La pyramide des tests : élément incontournable à respecter dans vos projets !
2. Pourquoi laisser de côté les risques produit peut nuire à votre projet IT ?
3. L’Analyse d’Impact : Clé de l’Agilité et de la Qualité Logicielle
4. L’agilité en V : une approche hybride pour une meilleure qualité logicielle
5. La Culture de la Qualité : pourquoi un testeur dédié est indispensable ?
6. Pourquoi il est urgent d’intégrer les testeurs dès le début du cycle de développement