Comment rédiger de bons critères d'acceptation ?

Comment rédiger de bons critères d'acceptation ?

16 Juin 2020

Les critères d’acceptation sont un composant absolument essentiel dans la rédaction d’une User Story ou Récit Utilisateur !

Normalement, une US ne peut être considérée comme prête si elle ne possède pas ces fameux critères d’acceptation.

Que sont exactement ces critères d’acceptation ? Comment les rédiger ? Qui doit les écrire ? Bref, comment rédiger de bons critères d’acceptation ?

Que sont les critères d’acceptation ?

Les critères d'acceptation définissent la manière dont une fonctionnalité particulière peut être utilisée du point de vue de l'utilisateur final. Ils se concentrent sur la valeur commerciale, définissent les limites de la portée de la fonctionnalité et guident le développement. Ils sont uniques à une User Story et constituent la base des tests d'acceptation de la User Story qui établissent les conditions du succès de la fonctionnalité.

Les critères d'acceptation peuvent établir une limite qui aide les membres de l'équipe à comprendre ce qui est inclus et ce qui est exclu de la portée de la User Story. Ainsi, ils n’informent pas seulement sur le comportement du produit dans des scénarios de parcours heureux, ils guident également l'expérience utilisateur lorsque les choses ne fonctionnent pas comme prévu en décrivant ce qui serait vérifié par les tests d'acceptation.

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

Puisque les critères d'acceptation concernent le client et l'équipe, c'est soit le client, soit un membre de l'équipe du projet qui est censé l'écrire.

Cependant, le Product Owner est celui qui les écrit généralement, surtout s'il a une connaissance adéquate du développement logiciel et de la rédaction des critères d'acceptation.

Par ailleurs, Il serait désorientant d'écrire des critères d'acceptation une fois que le développement a commencé. Les critères d'acceptation sont documentés et remplis avant le début du projet, car l'équipe et le client parviennent à un accord sur la quantité de travail qui répondra aux exigences du client.

Comment rédiger les critères d’acceptation ?

Il existe plusieurs types de critères d'acceptation. Les plus courants sont orientés règles (sous forme de liste) et orientés scenario (illustrant chaque critère).

Le type orienté scenario s’appuie sur le langage Gherkin de l’éditeur Cucumber : https://cucumber.io/docs/gherkin/reference/

Il est très populaire parmi les équipes Agile car il aide à franchir les exigences, à envisager divers cas d'utilisation et à utiliser davantage de scénarios pour des tests d'acceptation manuels et automatisés.

Le modèle commun pour décrire les critères d'acceptation à l'aide d'une approche orientée scénario se base sur le format anglophone Given / When / Then dérivé du développement piloté par le comportement (BDD). Le format Given (Etant Donné) / When (Quand ou Lorsque) / Then (Alors) est utilisé pour écrire des tests d'acceptation qui garantissent que toutes les exigences de spécification sont respectées.

Ce format est pratique pour les humains (car il est écrit de manière familière de cause à effet).

Exemple : types d’utilisateurs d’un site web

Par exemple, lorsque nous créons un site Web qui a deux types d'utilisateurs - les utilisateurs connectés et les invités - nous sommes susceptibles d'écrire les critères d'acceptation suivants pour une User Story qui définit la fonctionnalité de connexion pour un utilisateur déconnecté :

  • En tant qu'utilisateur déconnecté
  • Je souhaite pouvoir me connecter au site Web
  • Afin que je puisse accéder à mon profil personnel

Critères d’acceptation sous forme de scenario ( langage Gherkin) :

  • Scenario : L'utilisateur système se connecte avec des informations d'identification valides
  • Étant donné que je suis un utilisateur système déconnecté et que je suis sur la page de connexion,
  • Lorsque je remplis les champs «Nom d'utilisateur» et «Mot de passe» avec mes informations d'authentification et que je clique sur le bouton Connexion,
  • Alors le système me connecte









Exemple : recherche d’un ouvrage par un abonné d’une médiathèque

Deuxième exemple, la recherche d’un ouvrage sur le site d’une médiathèque. L’US, dont le titre est « Consulter la fiche d’un ouvrage » se décrit comme :

  • En tant qu’abonné de la médiathèque
  • Je recherche un ouvrage en spécifiant son auteur, son titre ou sa référence
  • Afin que l’emprunter ou de le réserver

Critères d’acceptation sous forme de liste :

  1. Résultat unique, afficher l’ouvrage : auteur/titre/reference
  2. Pas de résultat, inviter l’abonné à une nouvelle recherche
  3. Plusieurs résultats, afficher la liste des ouvrages triés par auteur

Critères d’acceptation sous forme de scenario ( langage Gherkin) :

  • Scenario : l’abonné lance une recherche pour consulter la fiche d’un ouvrage
  • Étant donné que je suis abonné et que je suis sur la page de recherche d’un ouvrage
  • Lorsque je saisis l’auteur, le titre ou la référence et que je lance la recherche
  • Alors je peux consulter la liste des ouvrages correspondants triés par auteur

User Story avec critères d'acceptation en langage Gherkin

Il est préférable d’écrire les critères d'acceptation avec le «je» à la première personne, car cela aide à parler du point de vue de l'utilisateur et à garder à l'esprit ses besoins.

Voici quelques conseils qui vous aideront à rédiger d'excellents critères d'acceptation :

  • Gardez vos critères bien définis afin que tout membre de l'équipe de projet comprenne l'idée que vous essayez de transmettre.
  • Gardez les critères réalistes et réalisables. Définissez la fonctionnalité minimale que vous êtes en mesure de fournir et respectez-la. D'un autre côté, n'essayez pas de décrire chaque détail car vous risquez d'encombrer votre backlog et d'être enterré sous de nombreuses petites tâches.
  • Coordonnez-vous avec toutes les parties prenantes afin que vos critères d'acceptation soient basés sur un consensus.
  • Créez des critères mesurables qui vous permettent d'estimer correctement le temps de développement afin de pouvoir respecter les contraintes de budget et de temps.

Caractéristiques des critères d’acceptation

Les critères d’acceptation sont les conditions de satisfaction d’un récit utilisateur :

  • Ils ont pour objectif de clarifier pour l’équipe de réalisation les attentes et exigences du métier.
  • Ils fixent les conditions qui permettent de satisfaire l’utilisateur.
  • Le Product Owner est garant des critères d’acceptation et de leur compréhension par l’équipe de réalisation, au même titre que la description du récit.
  • Le Product Owner accepte l’implémentation du récit utilisateur en fin de Sprint sur la base des critères d’acceptation.
  • Respecter seulement les critères d’acceptation ne signifie pas forcément la validation totale du récit. La validation définitive sera assurée par les tests fonctionnels.

Pour conclure, les critères d’acceptation sont indispensables car ils permettent de mettre tout le monde d’accord sur la manière dont va être vérifiée l’implémentation d’une US.

La description d’une US contient l’expression de besoin : « ce que je veux ».

Les critères d’acceptation contiennent la validation de l’US partagée par toute l’équipe : « Comment je vérifie que j’ai obtenu ce que je voulais ».

Et pour aller plus loin, les critères d'acceptation sont très utiles pour découper les User Stories trop grosses !

Laisser un commentaire

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