Les critères d’acceptation sont au cœur des cadres de travail Agiles. Ils sont même au centre de toute discussion sur le travail à accomplir. Toutefois, aussi importants qu’ils soient, peu de temps leur est dédié dans la plupart des formations Agiles. J’essaierai ici de remédier à la situation en mettant en lumière cet élément qui se trouve au cœur de la vie du Product Owner.

Que sont les critères d’acceptation?

Si le scénario utilisateur est l’élément qui nous permet de discuter d’un besoin, les critères d’acceptation sont le résultat de cette discussion. Ils servent à deux objectifs :

  1. Rappeler à tous ce qui définit le besoin auquel il faut répondre;
  2. Indiquer les validations à effectuer pour s’assurer que le besoin d’affaires est rempli.

Le Product Owner est responsable de s’assurer que tout travail prêt à débuter est décrit en termes de critères d’acceptation. C’est d’ailleurs grâce à eux et à la discussion qu’ils représentent que les équipes peuvent estimer l’effort de travail nécessaire pour remplir le besoin décrit.

À lire aussi : Améliorer la collaboration avec les scénarios utilisateurs

Quand et par qui sont écrits les critères d’acceptation ?

Il existe plusieurs bonnes réponses à cette question. Elles ont les points suivants en commun :

  • L’équipe est engagée dans la discussion autour des critères d’acceptation;
  • La connaissance du domaine d’affaires est transmise à l’équipe.

Voici quelques exemples de situations fréquemment rencontrées :

  1. Les critères d’acceptation se forment durant les exercices de raffinement du carnet de produit (grooming). Lors de ces exercices, le Product Owner et l’équipe s’échangent le clavier afin de documenter la conversation sous forme de critères d’acceptation. Cette méthode est à privilégier si vous considérez écrire vos critères sous forme d’exemples afin d’automatiser vos tests.
  2. L’équipe qui maîtrise bien le domaine d’affaires demande au Product Owner de faire un premier jet avec les critères d’acceptation afin d’optimiser l’efficacité lors des exercices de raffinement.
  3. L’équipe qui participe à la discussion sur les besoins à haut niveau (discovery session), laisse le Product Owner faire un premier jet avec les critères d’acceptation.
  4. Dans un contexte de multiéquipes pour un produit, des individus provenant d’équipes diverses participent à l’élaboration des critères d’acceptation.

Ce qu’on cherche à éviter est que le Product Owner ou l’analyste écrive « ses » critères d’acceptation et les présente à l’équipe sans qu’il y ait eu de discussion, surtout si cette dernière ne maîtrise pas le domaine d’affaires.

Est-ce que les critères d’acceptation décrivent le besoin d’affaires ou la solution ?

Les critères d’acceptation reflètent le comportement de l’utilisateur et détaillent son besoin.

Un bon point de départ est le scénario par défaut, celui qui ne présente pas d’exception ou d’erreur. Ainsi, un récit utilisateur pour permettre à un utilisateur de créer un compte pourrait avoir comme critères d’acceptation :

  • Considérant que <l’utilisateur> n’a pas déjà un compte dans le système, valider qu’il puisse en créer un avec son nom et son adresse de courriel.
  • Valider que l’utilisateur reçoit une confirmation que son compte a été créé.

Ensuite viennent les scénarios d’exception. Que se passe-t-il si un compte est déjà associé à ce courriel? Ou si l’utilisateur fournit de l’information erronée? Pour chaque exception, l’équipe pourra choisir entre la traiter par l’ajout de nouveaux critères d’acceptation ou par la création de nouveaux récits utilisateurs.

Concernant l’aspect solution, particulièrement les éléments d’interface et d’expérience utilisateur, l’équipe devrait avoir la capacité de faire ce travail de manière autonome. Dans la mesure du possible, il faut éviter d’avoir des étapes de création graphique et d’expérience utilisateur en amont au développement afin de ne pas mener à la création de silos professionnels.

Certains critères d’acceptation peuvent aussi documenter des prérequis non fonctionnels tels que la performance ou la conformité à certaines normes.

Quel est le meilleur format pour écrire les critères d’acceptation?

Les critères d’acceptation peuvent prendre plusieurs formes. Ils peuvent être écrits comme des petits récits utilisateurs, ou prendre la forme d’exemples afin de faciliter l’automatisation de tests d’acceptation (« Specifications by Example »), ou même être simplement une liste de points à vérifier. Toutes ces formes sont valides si :

  • Chaque critère d’acceptation peut clairement être défini comme « rempli ou pas ».
  • Chaque critère d’acceptation est testable.
  • Chaque critère d’acceptation ajoute une valeur au produit.

En quoi consistent les tests d’acceptation?

Les tests d’acceptation sont les tests utilisés afin de valider que les critères d’acceptation sont remplis. Ces tests sont souvent manuels. Toutefois, avec l’émergence de méthodes de développement orienté besoin telles que le BDD et l’ATDD, ces tests sont codés.

Récapitulation

Le plus important est de ne pas croire que les critères d’acceptation sont des versions légères de cas d’utilisation (« use cases ») ou des scénarios de tests. Ces derniers peuvent être laborieux à écrire et difficile à bien comprendre alors que les critères d’acceptation se veulent simples, clairs et collaboratifs.   Les mots clés sont : Collaboration, Besoin, et Validation.

Billet précédent

Le Bracket Show - Épisode 2

Billet suivant

Urban Turtle : Neuf ans de voyage d’une tortue autour du monde

Luc St-Laurent

Luc est un professionnel certifié Scrum (CSP) et un coach Agile. Il a commencé son trajet dans les technologies de l'information il y a plus de 20 ans, et ce, bien avant d’adopter les valeurs Agiles (2007). Il se dévoue à aider les équipes et les gestionnaires à mieux collaborer afin de livrer un meilleur produit entre les mains de l’utilisateur. Luc croit au développement personnel au sein de l’équipe et au développement de l’équipe au sein de l’organisation. Il aspire à croire au développement de l’organisation au sein de notre société.

2 Commentaires

  1. charlesandrebouchard@gmail.com'
    08/03/2017 at 08:27 — Répondre

    Merci pour ce billet! J’ai quelques questions à ce sujet:

    1 – Comment gérez-vous la documentation des critères d’acceptation « réguliers », c’est-à-dire ceux concernant des requis non-fonctionnels qui se répètent à travers les différentes fonctionnalités d’un projet?

    Par exemple, dans le contexte d’une application Web, je désire qu’à chaque fois qu’une opération est déclenchée par un utilisateur en cliquant sur un bouton, un icône de chargement en cours s’affiche dans le bouton et que celui-ci soit temporairement désactivé. Bien qu’il s’agisse tangiblement d’un critère d’acceptation, cela ne risquerait-il pas de faire gonfler la description de mes tâches au fur et à mesure que j’accumule ces critères réguliers?

    2 – À quel niveau de profondeur devrait s’arrêter la rédaction des critères d’acceptation?

    En reprenant l’exemple précédent, je fais face à un dilemme : si je m’attarde à rédiger chacun de ces critères, je m’assure d’une consistance au niveau de mes interfaces, au prix d’un gonflement de la description des fonctionnalités; en contrepartie, si je ne m’en tiens qu’à la description des besoins de l’utilisateur, je risque une implémentation inégale de mes interfaces.

    • 16/03/2017 at 11:13 — Répondre

      Merci pour tes questions. Idéalement, l’équipe agile possède toutes les compétences afin de livrer une solution de qualité à une demande d’affaires. Dans ce cas, les critères d’acceptation demeurent aux niveaux affaires et l’équipe s’occupe des considérations d’expérience usager et d’interface. Si ce n’est pas le cas, le PO peut demander à l’équipe quel serait le bon niveau de détails qui la motiverait à livrer un meilleur produit. Si la solution est trop définie en amont, on risque perd l’esprit de collaboration et on risque de nuire à l’innovation.

      L’approche est similaire pour les aspects non-fonctionnels. En partageant la problématique avec l’équipe de développement, le PO ouvre la porte à plusieurs solutions. Chez certaines équipes, j’ai vu apparaître des Wikis de normes non-fonctionnels et d’expérience usager. Dans d’autres, la définition du Done était utilisée. Dans une autre équipe, j’ai vu un développeur s’intéresser aux pratiques d’expérience usager, et augmenter ses compétences au point de permettre à l’équipe de prendre complètement la solution en charge. Rien ne peut battre la collaboration. Bonne chance.

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *