Modèle d'histoire utilisateur et critères d'acceptation

Le modèle de « user story » se présente sous la forme d’une phrase comportant trois espaces vides :

En tant que [rôle], je souhaite [objectif], afin que [avantage].

Copiez-le, utilisez-le, mais sachez à quoi il sert : ce modèle est un point de départ pour une discussion, et non un formulaire à remplir. C’est à partir d’une phrase complétée que le travail de précision commence. Ce qui rend l’histoire exploitable, ce sont les éléments qui s’y ajoutent ensuite : les critères d’acceptation qui transforment une intention convenue en un test de réussite ou d’échec, et l’estimation qui la transforme en un travail planifiable. Ce chapitre suit une histoire à travers ces trois étapes.

Remplir les espaces vides sans inventer de réponses

Chaque emplacement présente un défaut de fonctionnement courant, et chaque défaut peut être vérifié :

• [rôle] : une personne bien précise, jamais « un utilisateur ». Si vous ne parveniez pas à identifier cette personne dans vos statistiques ou dans votre file d’attente d’assistance, ce rôle n’est qu’une simple formalité. Test : un concepteur pourrait-il prendre une décision différente en raison du rôle que vous avez choisi ?
• [objectif] : ce que fait la personne, selon ses propres termes. « Je souhaite réinitialiser mon mot de passe » relève de l’utilisateur ; « Je souhaite un microservice de réinitialisation de mot de passe » relève du schéma d’architecture. Test : la personne prononcerait-elle réellement cette phrase ?
• [avantage] : l’argument justifiant la planification du travail. Test : supprimez cette clause. Si rien n’est perdu, c’est que l’avantage n’a pas encore été identifié.

L’explication complète de ce format (y compris les trois « C » et la liste de contrôle INVEST à laquelle une user story achevée doit se conformer) figure dans la section « Qu’est-ce qu’une user story ? ». Seize exemples concrets, positifs et négatifs, sont présentés dans la section « Exemples de user stories ».

Une fiche de projet « copier-coller »

Cette phrase à elle seule ne suffit pas pour se lancer dans un sprint. Voici le modèle complet de fiche qu’il convient d’adopter, comprenant le descriptif, les critères, les limites et la taille, cette dernière étant ajoutée en dernier :

Story
  As a [role], I want [goal], so that [benefit].

Acceptance criteria (3–5, each pass/fail)
  - [ ] …
  - [ ] …
  - [ ] …

Out of scope
  - What this story deliberately does NOT cover.

Notes & dependencies
  - Designs, decisions, other teams, open questions.

Size: [added by the team, after the conversation — never before]

Cette carte reflète deux choix délibérés. « Hors périmètre » est déterminant : la plupart des désaccords en matière d’estimation surviennent lorsque deux personnes évaluent des périmètres différents, et cette seule ligne permet de les éviter. L’estimation vient en dernier : un chiffre inscrit sur la carte avant que l’équipe n’en discute devient un point d’ancrage, ce qui constitue la première des erreurs classiques du Planning Poker.

Variantes de modèles

Le modèle classique est le choix par défaut approprié, mais ce n’est pas la seule forme qui convienne.

Variante	Forme	N’hésitez pas à l’utiliser lorsque
Classic (Connextra)	En tant que [fonction], je souhaite [objectif], afin que [avantage]	La configuration par défaut pour les tâches destinées aux utilisateurs
Description du poste	Lorsque [situation], je souhaite [motivation], afin de pouvoir [résultat]	Le moment déclencheur en dit plus long que le profil (une même personne a des attentes différentes dans un train et à son bureau)
Priorité aux avantages	Afin de [bénéficier de], en tant que [fonction], je souhaite [objectif]	L’équipe continue de rédiger des avantages circulaires ; le fait de placer cette clause en premier empêche de la sauter
Énoncé clair du problème	Une phrase décrivant le problème, une autre décrivant le résultat, ainsi que les critères de « fin de tâche »	Travaux liés à la plateforme et aux aspects techniques, pour lesquels la seule entité digne de confiance serait l’équipe elle-même

La dernière ligne a plus d’importance qu’il n’y paraît. Certains éléments du backlog ne mentionnent aucun utilisateur dans la phrase, et prétendre le contraire conduit à des formulations de remplissage telles que « en tant que développeur, je souhaite que le framework soit mis à jour ». La rigueur imposée par le modèle (une raison clairement énoncée associée à des critères vérifiables) s’applique à ce travail ; la forme de la phrase, quant à elle, n’a pas besoin de l’être.

Critères d’acceptation : la confirmation figurant sur la carte

Les critères d’acceptation correspondent aux conditions de réussite ou d’échec de l’histoire, rédigées avant le début des travaux. Sur la fiche, ils remplissent deux fonctions : ils restituent ce qui a été effectivement convenu lors de la discussion de précision, et ils définissent la ligne d’arrivée sur laquelle portera l’estimation. Deux formats couvrent la quasi-totalité des histoires :

Une simple liste de contrôle, pour les conditions indépendantes :

• Le contenu du panier est conservé pendant 30 jours, d’une session à l’autre.
• Un client fidèle peut voir son panier depuis n’importe quel appareil sur lequel il est connecté.
• Un panier vidé reste vide (les articles supprimés ne réapparaissent pas).

Si/Quand/Alors, pour les comportements qui dépendent de l’état :

• Si un client a un panier enregistré, **lorsqu’**un article est en rupture de stock, alors cet article apparaît dans le panier en gris, accompagné de la mention « en rupture de stock », au lieu d’être supprimé sans avertissement.

Privilégiez la liste de contrôle ; recourez à la méthode « Given/When/Then » lorsque la condition préalable implique un véritable travail. Limitez la liste à trois à cinq éléments. Une liste plus longue signifie généralement que l’histoire doit être scindée, et ce sont les critères qui vous indiquent où effectuer cette coupure. Pour une approche complète (critères vs exigences, critères vs définition de « terminé », qui les rédige), consultez le chapitre consacré aux critères d’acceptation.

Exemple concret : un étage, modèle d’estimation

Voici le déroulement d’une histoire vraie, à partir de la carte ci-dessus.

Étape 1 : le scénario. Le Product Owner rédige :

En tant que nouveau client, je souhaite passer commande sans créer de compte, afin de pouvoir finaliser mon achat avant de changer d’avis.

Étape 2 : la conversation, consignée sous forme de critères. Lors de l’affinage du backlog, l’équipe met en évidence les nuances que la phrase ne laisse pas transparaître et les note :

• Un acheteur peut finaliser sa commande en indiquant uniquement son adresse e-mail et ses coordonnées de livraison, sans mot de passe.
• L’e-mail de confirmation de commande vous permet de créer un compte en un seul clic (commande déjà jointe).
• Le service client peut retrouver une commande passée en tant qu’invité à l’aide du numéro de commande et de l’adresse e-mail.
• Le paiement en tant qu’invité est soumis aux mêmes contrôles anti-fraude que le paiement via un compte.

Hors du champ d’application : la conversion des commandes historiques des clients lorsqu’un compte est créé a posteriori.

Étape 3 : la vérification de l’état de préparation. Quatre critères, une exclusion explicitement mentionnée, aucune dépendance non confirmée : la story répond aux critères de préparation et est transmise à l’équipe pour l’estimation.

Étape 4 : l’estimation. L’équipe vote lors d’un tour de « planning poker ». Les cartes tirées sont 3, 5, 5, 8. Le 8 s’explique ainsi : le critère de contrôle anti-fraude implique de modifier l’intégration du prestataire de paiement, ce que personne d’autre n’avait pris en compte dans son estimation. C’est là que les critères remplissent véritablement leur rôle : la discussion porte sur le périmètre, et non sur la question de savoir quel chiffre est le bon. L’équipe procède à un nouveau vote et s’accorde sur le chiffre 5.

Remarquez l’ordre des étapes : les critères d’abord, puis les points. Une story évaluée avant même que ses critères n’aient été définis entraîne des écarts importants et insolubles qui bloquent les sessions de détermination de la taille. L’équipe finit par voter sur différentes stories qui partagent simplement le même titre.

Foire aux questions

Qu’est-ce que le modèle d’histoire utilisateur ?

« En tant que [rôle], je souhaite [objectif], afin que [avantage]. » Le rôle désigne la personne qui bénéficie de la valeur, l’objectif définit la capacité en termes compréhensibles pour cette personne, et l’avantage est la raison pour laquelle cette tâche mérite de figurer dans le backlog. Ce modèle sert à amorcer une conversation, et non à remplir un formulaire. C’est en complétant les espaces vides que commence le travail d’affinage.

Comment rédigez-vous les critères d’acceptation d’une user story ?

Rédigez trois à cinq conditions vérifiables qui indiquent, par « réussi » ou « échoué », si l’histoire a bien respecté ce qui avait été convenu. Utilisez une simple liste de contrôle lorsque les conditions sont indépendantes, et la structure « Given/When/Then » lorsque le comportement dépend d’un état. Chaque critère doit pouvoir être vérifié par un testeur n’ayant jamais assisté à la discussion de raffinement.

Faut-il utiliser la structure « Given/When/Then » ou une liste de contrôle pour les critères d’acceptation ?

Adaptez le format au comportement. La structure « Given/When/Then » prend tout son sens lorsque le résultat dépend d’un état initial, car elle vous oblige à nommer la condition préalable, le déclencheur et le résultat. Une liste de contrôle est plus rapide à lire et plus difficile à gonfler lorsque le scénario se résume simplement à « ces quatre éléments doivent être vérifiés ». La plupart des scénarios ne nécessitent que la liste de contrôle.

Qu’est-ce qu’un « job story » ?

Une variante qui remplace le persona par une situation : « Lorsque [situation], je souhaite [motivation], afin de pouvoir [résultat]. » Les « job stories » s’inspirent de l’approche « jobs-to-be-done » et s’avèrent particulièrement efficaces lorsque le moment déclencheur explique mieux le besoin qu’un persona. Une même personne n’a pas les mêmes attentes lorsqu’elle est à son bureau que lorsqu’elle est dans le train.

Chaque élément du backlog doit-il obligatoirement respecter le modèle d’histoire utilisateur ?

Non. Le modèle décrit la valeur perçue par l’utilisateur, et le fait de l’appliquer de force au travail sur les plateformes, aux bogues connus ou aux pics de recherche donne lieu à des phrases qui ajoutent de la formalité sans apporter d’informations. Conservez les deux éléments qui s’appliquent toujours (une raison clairement énoncée et des critères d’acceptation vérifiables), et laissez la structure de la phrase s’adapter au travail concerné.

Lectures complémentaires

• Estimation agile : le guide complet : retrouvez ici toutes les informations nécessaires.
• Qu’est-ce qu’une « user story » ? : la logique qui sous-tend le modèle, les trois « C » et le principe INVEST.
• Exemples d’histoires utilisateur : seize histoires annotées servant de référence.
• Critères d’acceptation : comment les rédiger : le chapitre complet consacré à l’étape de validation.
• Définition de « prêt » : l’étape qu’une tâche modélisée doit franchir pour être intégrée au sprint.
• Que sont les « story points » ? : l’unité de mesure utilisée pour évaluer la taille d’une carte une fois terminée.