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. Une phrase complétée marque le début du travail de précision. 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 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 — se trouve dans Qu’est-ce qu’une user story ?. Seize exemples concrets, bons et mauvais, sont présentés dans Exemples de user stories.

Une fiche de projet « copier-coller »

Cette phrase à elle seule ne suffit pas pour lancer un sprint. Voici le modèle complet de fiche qu’il convient d’adopter : l’histoire, les critères, les limites et, enfin, la taille :

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]

Deux choix délibérés dans cette carte. « 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 ligne permet justement de les éviter. La taille 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 valeur 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 personnage : la même personne dans un train n’a pas les mêmes envies que lorsqu’elle est assise à 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 est plus importante 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, définies avant le début des travaux. Sur la fiche, ils remplissent deux fonctions : ils restituent ce qui a été convenu lors de la discussion de précision, et ils définissent la ligne d’arrivée vers laquelle s’orientera l’estimation. Deux formats couvrent la quasi-totalité des histoires :

Une liste de contrôle simple, 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 retirés ne réapparaissent pas).

Given/When/Then, pour les comportements qui dépendent de l’état :

• **Lorsqu’**un client dispose d’un panier enregistré, si 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 travail concret. Limitez la liste à trois à cinq éléments : une liste plus longue signifie généralement que l’histoire devrait être divisée, et les critères vous indiquent les points de rupture. Pour une analyse complète (critères vs exigences, critères vs définition de « terminé », qui les rédige), consultez le chapitre sur les 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 nouvel acheteur, je souhaite passer à la caisse 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 du raffinage du backlog, l’équipe met en évidence les nuances que la phrase ne permet pas de rendre 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 lorsque leur 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 à la définition de l’état 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 vérification des fraudes 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.

Notez l’ordre des étapes : les critères d’abord, puis les points. Une story estimé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 dimensionnement — l’équipe vote alors sur des stories différentes qui se trouvent simplement partager 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 d’obtenir [avantage]. » Le rôle désigne la personne qui bénéficie de la valeur, l’objectif définit la capacité en termes propres à 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’affinement.

Comment rédige-t-on 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 artificiellement 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’école des « 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 utiliser 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 plateforme, aux bogues connus ou aux projets de recherche ponctuels 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

• L’estimation agile : le guide complet — la plateforme de référence pour tout ce qui concerne ce sujet.
• Qu’est-ce qu’une user story ? — le raisonnement qui sous-tend ce 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 story modélisée doit franchir pour être intégrée au sprint.
• Que sont les « story points » ? — l’unité utilisée pour évaluer la taille d’une carte une fois terminée.