Dans la méthode Agile, l’acceptance criteria correspond à un ensemble de besoins prédéfinis qui doivent être satisfaits pour qu’une user story soit considérée comme étant terminée. Les acceptance criteria déterminent la portée et les exigences à exécuter par les développeurs pour qu’une user story soit considérée comme finie. En tant que Product Manager ou Product Owner, vous pouvez être amené à rédiger ces acceptance criteria pour les stories de votre backlog produit. Cet article définit les acceptance criteria, présente quelques exemples et explore des bonnes pratiques pour les rédiger.
Sommaire
Acceptance critéria : Définition
Dans la méthodologie agile, l’acceptance criteria ou critère d’acceptation représente une forme de documentation des besoins, qui précise ce qu’un produit ou un projet doit contenir pour être accepté par un utilisateur, client ou autre partie prenante.
Voici quelques définitions proposées par le secteur :
« Pre-established standards or requirements a product or project must meet. » Google
« Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder. » Microsoft Press
Vous l’aurez compris, les acceptance criteria fixent la portée et les exigences des user stories. Elles fournissent aux développeurs le contexte nécessaire pour implémenter la story. Vous pouvez visionner notre courte vidéo explicative ci-dessous.
Quels sont les caractérisitiques d’une acceptance criteria efficace ?
Les critères d’acceptation doivent avant tout être testables. Comme ces besoins contribuent à la définition du « done » pour vos développeurs , ils doivent être faciles à tester. Les tests doivent renvoyer des résultats clairs, sans ambiguïté (oui/non ou pass/fail). Voici ce que vous devez retenir :
- Les critères doivent être clairs et concis. Il ne s’agit pas de rédiger une documentation complète, mais de rester simple et explicite.
- Tout le monde doit comprendre vos acceptance criteria. Ces derniers sont inutiles si vos développeurs ne les comprennent pas. Si vous avez le moindre doute, prenez le temps de demander des retours et d’ajuster les critères jusqu’à ce qu’ils soient limpides.
- Les acceptance criteria doivent adopter la perspective utilisateur. Elles doivent être rédigées dans le contexte d’une expérience réelle du client.
Pourquoi avoir besoin de critères d’acceptation pour les user stories ?
Les acceptance criteria remplissent plusieurs fonctions pour les équipes cross-fonctionnelles.
Une user story seule laisse place à de nombreuses interprétations. Les critères d’acceptation clarifient de manière concrète les résultats attendus de la story, et offrent aux développeurs ainsi qu’aux QA une méthode claire pour déterminer si la story est « faite ».
Intégrer ces critères dans votre processus présente de nombreux avantages. Tout d’abord, définir l’issue désirée avant le développement permet de promouvoir l’alignement et la compréhension partagée, réduisant ainsi les mauvaises surprises en cours de sprint.
En plus d’aider les Product Managers et Owners à définir et gérer les attentes, les acceptance criteria sont également très utiles pour les développeurs. Le contexte supplémentaire diminue l’ambiguïté et crée une excellente défense contre le scope creep. En effet, s’il manque un besoin défini en début de sprint, il est plus facile qu’il y ait une dérive des objectifs. Finalement, ces derniers déterminent souvent les tests fail/pass qui seront effectués pour valider l’achèvement d’une user story.
Qui rédige les acceptance criteria ?
Pratiquement n’importe quel membre de l’équipe produit peut apporter sa contribution à l’écriture des critères d’acceptation pour les user stories. Généralement, le Product Owner ou le Product Manager est responsable de leur rédaction, ou du moins de la facilitation de la discussion à ce sujet. L’objectif est de s’assurer que les besoins sont rédigés en tenant compte des attentes des utilisateurs. Et qui mieux qu’une personne du produit peut comprendre ces besoins ?
Ceci dit, il est largement recommandé de faire de la rédaction des critères d’acceptation une activité de groupe incluant des représentants du développement et du QA. Faire participer les développeurs et les QA permet :
- Une meilleure communication sur la stratégie et la vision produit.
- L’identification de pièces manquantes ou de dépendances qui n’étaient pas évidentes initialement.
- Une meilleure compréhension, du point de vue des développeurs, de ce à quoi ressemblent vos user stories.
Ainsi, dans la mesure du possible, rédigez la « definition of done » en équipe.
Quand rédiger les acceptance criteria ?
De nombreux Product Managers et Product Owners choisissent de rédiger les acceptance criteria lors des sessions de backlog grooming. Ils les apportent ensuite aux réunions de sprint planning pour les discuter avec les développeurs, et affiner les critères en fonction de leurs retours.
Il n’existe pas de règle stricte sur le moment précis où il faut rédiger ces exigences, mais au plus tard, elles doivent être définies avant le début du développement. Sinon, vous perdez une grande partie des avantages offerts par ces critères.
Cependant, rédiger ces critères trop tôt peut aussi se retourner contre vous. En effet, la méthodologie agile encourage la réévaluation fréquente des priorités en fonction des nouvelles découvertes. Cela signifie que des user stories peuvent être re-priorisées d’un sprint à l’autre.
Une façon de gérer cette incertitude consiste à ne rédiger les acceptance criteria qu’au moment de déplacer une story dans le sprint backlog. Ainsi, vous ne perdez pas de temps à formaliser des besoins pour des user stories qui pourraient être dépriorisées. Une fois la story intégrée dans le sprint backlog, il est facile d’identifier qu’elle sera abordée prochainement. Vous pouvez donc commencer par définir des exigences de manière approximative, puis les finaliser lors du sprint planning en discussion collective.
Comment formater les acceptance criteria d’une user story ?
Il n’existe pas une seule manière « correcte » de rédiger les acceptance criteria pour une user story. L’essentiel est d’établir un format et une procédure adaptés à votre équipe. Un peu d’expérimentation peut être nécessaire si vous débutez. La plupart des organisations agiles utilisent l’un de ces deux formats :
Acceptance criteria : Le format given/when/then
Le format Given/When/Then est celui que j’affectionne le plus. Il est similaire au format traditionnel des user stories. La user story suit généralement le modèle : « En tant que (utilisateur ciblé), je souhaite (action désirée), afin de (résultat attendu) ». Les acceptance criteria en format Given/When/Then suivent le modèle :
« Scenario : (description du scénario)
Given (état initial),
When (action effectuée),
Then (résultat attendu). »
Cela peut sembler confus au début, jusqu’à ce que vous voyiez un exemple concret d’association d’une user story et d’acception criteria au format Given/When/Then. Voici un exemple :
Exemple d’acceptance criteria – format given/when/then
User story :
En tant que Product Manager,
Je souhaite pouvoir scorer des idées potentielles,
Pour déterminer ce qu’il faut intégrer à ma roadmap produit.
Acceptance criteria pour cette user story :
Scenario : Le Product Manager ajoute des idées potentielles et classe les meilleures en fonction du rapport bénéfice/coût.
• Given que j’ai ajouté deux idées ou plus et les ai notées selon le modèle Benefit vs Cost,
• When je clique sur le bouton Rank,
• Then les idées sont triées avec celles ayant le meilleur score en premier.
Acceptance criteria : Le format checklist
La mise en forme sous forme de checklist est une autre option pertinente. Elle est très simple à mettre en œuvre. Le groupe définit ensemble une liste d’éléments sous forme binaire (pass/fail) que la fonctionnalité doit respecter pour être validée.
Au final, le format importe moins que sa praticité : si votre équipe le comprend et peut s’y référ
