Chaque User Story a ses propres Critères d'acceptation, Oui mais qui les formalise ?

La création et la l'affinage d'une User Story passe comme déjà connu par les agilistes par trois phases séquentielles, ou ce quand appelle le modèle "3C" :

Card : la demande est sous Forme d'une idée initiale déclenchée par les parties prenantes sous forme de petits mots expliquant le besoin, ou par un utilisateur final suite à un besoin souhaité de sa part.

Conversation : L'idée posée devient un sujet de discussion et d'affinage pour détailler son objectif, valoriser sa valeur métier, expliquer et poser l'ensemble des règles de gestion associées, ...Etc.

Confirmation : L'équipe de développement se met d'accord avec le PO sur une seule vision formelle, complète et finale de l'User Story avec ses critères d'acceptation et la D.o.R (Definition Of Ready).

Les critères d'acceptation sont un ensemble de conditions à tester, vérifier, et satisfaire par l'User Story afin qu'elle soit complète, terminée, et acceptée par le Product Owner et les parties prenantes à la fin de Sprint, c'est le résultat de la compréhension du besoin partagée par les différents acteurs (Product Owner, équipe de développement, testeurs, parties prenantes, ...Etc.).

La question qui se pose souvent c'est qui formalise ces critères d'acceptation ? Est ce le Product Owner ? Les développeurs ? ou l'étroite collaboration de tous les acteurs et rôles concernés ?

Sur le terrain on peut trouver plusieurs cas de figure :

• Les critères d'acceptation sont rédigés et formalisés par le Product Owner.

• Les critères d'acceptation sont rédigés et formalisés par les développeurs et validés par le Product Owner pour montrer qu'ils ont bien compris le besoin en question.

• Les critères d'acceptation sont rédigés et formalisés par le Product Owner et l'équipe de test associée.Les critères d'acceptation sont rédigés et formalisés par le Product Owner et les développeurs ensemble.

• Les critères d'acceptation sont rédigés et formalisés par tous les acteurs impactés et concernés (Parties prenantes, Product Owner, Testeurs, et Développeurs).

Ce que je recommande vivement comme étant Coach agile est le dernier cas cité ci-dessus car si tous les acteurs collaborent et formalisent ces critères d'acceptation ensemble, on va s'assurer que le besoin est compris de la même manière par les différents acteurs, et qu'on a une vision unique et partagée par tout l'écosystème, ce qui va empêcher la perte du temps et les aller-retours.

Conclusion :

Que sa soit pour les critères d'acceptation ou autre aspect de l'agilité, on favorise toujours la participation et la collaboration de tous les acteurs et intervenants à la fois, permettant la bonne compréhension partagée et le même objectif à atteindre.

Pour une bonne formalisation des critères d'acceptation, il est toujours souhaitable de s'inspirer du langage "GHERKIN" utilisé pour les tests automatisés (Given, When, Then), et cela pour la meilleure description du comportement du système ou du logiciel lié à la fonctionnalité ou l'User Story en question.