Modèle de user story avec critères d'acceptation (Gratuit)

Un modèle d’histoire utilisateur remplit deux fonctions. Il permet à chaque histoire de répondre aux mêmes trois questions (qui, quoi, pourquoi), et il offre à l’équipe un emplacement fixe pour noter comment elle saura que l’histoire est terminée. Cette page vous fournit les deux : le format d’histoire en une ligne, un modèle de carte complet que vous pouvez copier, des critères d’acceptation en trois formats, une définition de la préparation et de l’achèvement, ainsi que des exemples concrets.

Si vous êtes nouveau en matière d’histoires utilisateur, commencez par notre guide sur comment rédiger des user stories, puis revenez ici pour le modèle.

Le modèle d’histoire utilisateur en une ligne

La plupart des équipes utilisent le format issu de l’équipe Connextra à Londres en 2001 et popularisé par le livre de Mike Cohn, User Stories Applied (son aperçu des histoires utilisateur est une bonne introduction) :

En tant que [type d’utilisateur], je veux [une action ou une capacité], afin de [un bénéfice ou un résultat].

Chaque partie a une fonction spécifique :

• « En tant que » désigne un type d’utilisateur réel, tel qu’un acheteur pour la première fois, un administrateur de compte ou un patient récurrent. « En tant qu’utilisateur » ne dit rien à l’équipe. Si vous avez des personas, utilisez leurs noms.
• « Je veux » décrit ce que l’utilisateur fait ou obtient, en ses propres termes. Il ne doit pas décrire la solution (« un menu déroulant », « un cache Redis ») ; laissez de la place à l’équipe pour trouver la meilleure option.
• « Afin de » énonce la valeur. C’est la partie la plus souvent omise et la plus importante : c’est ainsi que l’équipe peut proposer une option plus simple qui produit le même résultat, et ainsi que le propriétaire du produit décide de la priorité.

Gardez à l’esprit que la phrase n’est pas la spécification. Ron Jeffries a décrit une histoire comme trois choses : la carte, la conversation et la confirmation (les 3 Cs). Un modèle aide pour la carte et la confirmation (les critères d’acceptation) ; rien ne remplace la conversation.

Le modèle de carte d’histoire utilisateur complet

La phrase unique suffit pour une note adhésive. Dans un outil de backlog, vous avez généralement besoin de quelques champs supplémentaires pour que l’histoire puisse être classée, estimée et testée. Voici les champs que nous trouvons utiles ; supprimez ceux que votre équipe ne lit jamais.

Gardez « Contexte et notes » court : si cela devient une page de spécification, l'histoire est probablement une épopée et doit être divisée (notre guide de cartographie des histoires montre comment).

Modèle d'histoire utilisateur prêt à copier

Collez ceci dans le champ de description d'un ticket Jira ou Linear, un modèle de base de données Notion, ou la ligne d'en-tête d'un tableur. Remplacez le texte entre crochets et supprimez les lignes que vous n'utilisez pas.

• ID : [PROJET-000]
• Titre : [Verbe + objet, par exemple « Exporter les factures en CSV »]
• Histoire : En tant que [type d'utilisateur], je veux [action ou capacité], afin de [bénéfice].
• Contexte : [Pourquoi cela compte maintenant ; lien vers des recherches, des tickets de support ou des métriques]
• Critères d'acceptation : [3 à 7 conditions testables, sous forme de liste de contrôle ou de Given/When/Then]
• Hors périmètre : [Ce que cette histoire ne couvre pas délibérément]
• Conceptions : [Lien vers le cadre ou le prototype]
• Dépendances : [Autres histoires, services ou décisions]
• Priorité : [Doit / Devrait / Pourrait, ou rang dans le backlog]
• Estimation : [Points ou taille, remplie par l'équipe]
• Questions ouvertes : [Tout ce qui doit être répondu avant le début du sprint]

La ligne « Hors périmètre » évite les débats : écrire « n'inclut pas la réinitialisation par SMS » sur la carte est préférable à découvrir lors de la revue de sprint que quelqu'un avait supposé le contraire.

Ce que sont les critères d'acceptation, et qui les rédige

Les critères d'acceptation sont les conditions qu'une histoire doit remplir pour être acceptée par le product owner. Ils décrivent le comportement observable du point de vue de l'utilisateur, et non le fonctionnement du code. De bons critères sont :

• Testables : quelqu'un peut répondre oui ou non sans interprétation. « Rapide » n'est pas testable ; « les résultats apparaissent en moins de deux secondes » l'est.
• Spécifiques à cette histoire : les règles qui s'appliquent à toutes les histoires (code revu, déployé en staging) appartiennent à la définition de la fin, pas ici.
• Dépourvus de détails d'implémentation : dites ce qui se passe, pas quel composant ou quelle table le rend possible.
• Honnêtes face à l'échec : au moins un critère couvre les entrées invalides, l'absence de réseau ou les permissions manquantes.
• Peu nombreux : trois à sept critères est une fourchette saine. Plus de dix signifie généralement que l'histoire doit être divisée.

Le product owner est responsable des critères, mais ne devrait pas les rédiger seul. Le schéma le plus fiable est une courte conversation d'affinage entre le produit, un développeur et un testeur (souvent appelés les « trois amis ») : quelle est la valeur, comment cela sera-t-il construit, comment cela pourrait-il échouer.

Format 1 : critères d'acceptation en liste de contrôle

Une simple liste de conditions. C'est le format le plus rapide à écrire et à lire, et il fonctionne bien pour les histoires simples et pour les équipes qui testent manuellement.

Histoire : En tant que client récurrent, je veux réinitialiser mon mot de passe par e-mail, afin de pouvoir accéder à nouveau à mon compte sans contacter le support.

• L'écran de connexion a un lien « Mot de passe oublié ? » qui ouvre le formulaire de réinitialisation.
• La soumission d'une adresse e-mail enregistrée envoie un lien de réinitialisation en moins d'une minute.
• Le lien de réinitialisation fonctionne une seule fois et expire après 30 minutes.
• Le nouveau mot de passe doit respecter les règles existantes, et le formulaire indique quelle règle a échoué.
• Après une réinitialisation réussie, toutes les autres sessions de ce compte sont déconnectées.
• La soumission d'une adresse non enregistrée affiche le même message de confirmation qu'une adresse enregistrée, de sorte que le formulaire ne révèle pas qui possède un compte.

Utilisez la liste de contrôle lorsque le comportement est simple. Son inconvénient est qu'elle masque l'état initial et l'ordre des événements, ce que le format suivant rend explicite.

Format 2 : Critères d'acceptation Given/When/Then (Gherkin)

Given/When/Then provient du développement piloté par le comportement, que Dan North a décrit avec Chris Matts dans Introducing BDD. Chaque scénario énonce un contexte de départ (Given), une action (When) et un résultat attendu (Then). Gherkin est la version structurée de ce langage utilisée par Cucumber et des outils similaires, de sorte que les scénarios rédigés ainsi peuvent devenir des tests automatisés avec peu de reformulation.

Voici la même histoire de réinitialisation du mot de passe en trois scénarios, y compris deux chemins non heureux.

Scénario 1 : réinitialisation avec un lien valide

• Étant donné que j'ai un compte enregistré à anna@example.com
• Et que j'ai demandé une réinitialisation du mot de passe
• Lorsque j'ouvre le lien de réinitialisation dans les 30 minutes et que j'entre un nouveau mot de passe qui respecte les règles
• Alors mon mot de passe est modifié
• Et je suis connecté
• Et mes autres sessions sont déconnectées

Scénario 2 : le lien a expiré

• Étant donné que j'ai demandé une réinitialisation du mot de passe il y a plus de 30 minutes
• Quand j'ouvre le lien de réinitialisation
• Alors je vois un message indiquant que le lien a expiré
• Et qu'on m'offre un bouton pour envoyer un nouveau lien

Scénario 3 : l'adresse e-mail n'est pas enregistrée

• Étant donné qu'aucun compte n'existe pour sam@example.com
• Lorsque je demande une réinitialisation du mot de passe pour sam@example.com
• Alors je vois le même message de confirmation qu'un utilisateur enregistré
• Et aucun e-mail n'est envoyé

Lorsqu'un scénario doit s'exécuter avec plusieurs entrées (par exemple, une liste de mots de passe qui doivent être rejetés), le Scenario Outline de Gherkin permet de l'écrire une fois et de lister les entrées dans un tableau d'exemples.

Gardez le Gherkin lisible : un comportement par scénario, et rédigez de manière déclarative (« Lorsque je demande un lien de réinitialisation ») plutôt que clic par clic (« Lorsque je clique sur le bouton Envoyer »), afin que le scénario survive à une refonte.

Format 3 : Critères d'acceptation basés sur des règles

Pour les histoires qui sont principalement des règles métier (tarification, éligibilité, validation, permissions), énoncez les règles directement et ajoutez des scénarios uniquement pour les combinaisons complexes.

Histoire : En tant qu'acheteur, je veux appliquer un code de réduction lors du paiement, afin de payer le prix promotionnel.

• Règle 1 : un code par commande.
• Règle 2 : un code en pourcentage s'applique uniquement au sous-total des produits, et non aux frais de port ou aux taxes.
• Règle 3 : un code avec un montant minimum s'applique uniquement lorsque le sous-total, avant la réduction, atteint le minimum.
• Règle 4 : les codes expirés ou épuisés sont rejetés avec un message qui explique pourquoi.
• Règle 5 : la suppression d'articles faisant baisser le sous-total en dessous du minimum supprime le code et affiche un avis.

Vous pouvez mélanger les formats dans une même histoire. Un schéma courant consiste à utiliser des règles pour la logique, plus deux ou trois scénarios Étant donné/Quand/Alors pour les cas que les gens sont le plus susceptibles de mal interpréter.

Définition de la préparation vs définition de la fin

Les critères d'acceptation sont spécifiques à une histoire. La définition de la préparation et la définition de la fin sont des accords d'équipe qui s'appliquent à chaque histoire.

Le Guide Scrum définit la définition de la fin comme la description formelle de l'état de l'incrément lorsqu'il répond aux mesures de qualité requises pour le produit. La définition de la préparation ne fait pas partie de Scrum ; c'est une pratique que de nombreuses équipes adoptent pour empêcher le travail mal compris d'entrer dans un sprint (voir le glossaire de l'Agile Alliance sur la définition de la préparation et définition de la fin).

Exemple de définition de la préparation

• L'histoire suit le modèle et le champ « afin que » est rempli.
• Les critères d'acceptation sont rédigés et revus par le produit, le développement et les tests.
• Les designs sont liés, ou l'équipe a convenu qu'aucun n'est nécessaire.
• Les dépendances sont terminées ou planifiées.
• L'équipe l'a estimé, et il tient dans un sprint.

Exemple de définition de la fin

• Tous les critères d'acceptation sont satisfaits.
• Le code est revu et fusionné dans la branche principale.
• Les tests automatisés couvrent le nouveau comportement et la suite complète réussit.
• Les vérifications de base d'accessibilité sont réussies (utilisation du clavier, libellés, contraste).
• Il est déployé sur l'environnement de pré-production et le propriétaire du produit l'a accepté.

Considérez la définition de la préparation comme une liste de contrôle pour l'affinement, et non comme une barrière. Si une équipe refuse chaque histoire qui ne coche pas une case, le travail ralentit et la conversation que l'histoire était censée initier n'a jamais lieu.

Exemples concrets

Deux autres histoires issues de différents types de produits. Pour en voir quarante autres, consultez notre exemples d'histoires utilisateur.

SaaS : inviter un collègue (liste de contrôle)

En tant qu'administrateur d'espace de travail, je souhaite inviter un collègue par e-mail, afin qu'il puisse voir nos projets sans que je partage mes identifiants.

• Les administrateurs voient un bouton « Inviter » sur la page des membres ; les autres rôles ne le voient pas.
• L'administrateur peut choisir le rôle (Membre ou Administrateur) avant l'envoi.
• L'e-mail d'invitation arrive dans l'heure et le lien est valide pendant sept jours.
• Inviter une adresse qui est déjà membre affiche un message au lieu d'envoyer une deuxième invitation.

E-commerce : enregistrer un article pour plus tard (Given/When/Then)

En tant qu'acheteur qui n'est pas prêt à acheter, je souhaite déplacer un article de mon panier vers une liste enregistrée, afin de pouvoir le retrouver sans que cela n'affecte le total de ma commande.

• Étant donné que je suis connecté et que j'ai deux articles dans mon panier
• Lorsque je choisis « Enregistrer pour plus tard » sur un article
• Alors cet article est déplacé vers ma liste enregistrée
• Et le total de mon panier est recalculé sans lui
• Étant donné que je ne suis pas connecté
• Lorsque je choisis « Enregistrer pour plus tard »
• Alors on me demande de me connecter, et l'article est enregistré une fois que je le fais

Utiliser le modèle dans Jira, Linear, Notion ou un tableur

Dans Jira, utilisez le type d'incident « Story » et collez le modèle dans la description (ou gardez les critères d'acceptation dans un champ dédié si votre administrateur en a ajouté un). Dans Linear, enregistrez-le comme modèle d'incident. Dans Notion, placez-le dans un modèle de base de données pour que les nouvelles pages de backlog s'ouvrent pré-remplies. Un tableur avec une ligne par histoire fonctionne pour un premier backlog ou un atelier, mais passez à un outil de suivi dès que plusieurs personnes le modifient. Quel que soit l'outil, gardez le modèle suffisamment court pour que les gens le remplissent.

Rédiger des histoires et des critères d'acceptation avec l'IA

Les modèles de langage sont bons pour un premier jet d'histoires et de critères. Un prompt qui fonctionne :

Vous êtes un chef de produit. Pour la fonctionnalité ci-dessous, rédigez des histoires utilisateur au format « En tant que [utilisateur], je souhaite [action], afin de [bénéfice] ». Pour chaque histoire, ajoutez 3 à 6 critères d'acceptation sous forme Given/When/Then, y compris au moins un chemin d'échec. Listez séparément les hypothèses et les questions ouvertes. Fonctionnalité : [décrivez la fonctionnalité, les utilisateurs et les contraintes éventuelles].

Ensuite, examinez le brouillon comme n'importe quelle autre entrée :

• L'utilisateur est-il un segment réel avec lequel vous avez parlé, ou un « utilisateur » générique ?
• Le modèle a-t-il inventé des règles métier, des limites ou des chiffres ? Remplacez-les par les vôtres.
• Les chemins d'échec sont-ils ceux que vos utilisateurs rencontrent réellement ? Un brouillon ne remplace jamais la conversation d'affinement.

Questions fréquemment posées

Voulez-vous qu'une équipe transforme vos histoires en logiciel fonctionnel ? Apportez votre backlog, ou juste l'idée, et nous vous aiderons à la façonner en histoires de taille de sprint et à la construire. Voir nos plans de développement mensuels.