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 type « réussi/échoué », 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 à partir de vos données d’analyse ou de 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 : cette phrase serait-elle réellement prononcée par la personne ?
• [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 du format (y compris les trois « C » et la liste de contrôle INVEST à laquelle une user story finalisée doit se conformer) figure 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 se lancer dans un sprint. Voici le modèle complet de fiche qu’il convient d’adopter comme norme, comprenant le contexte, les critères, les limites et la taille indiquée en dernier lieu :

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 fiche. « Hors périmètre » est un élément 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. 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èle

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

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 profil (une même personne dans un train n’a pas les mêmes attentes 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 rend impossible 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 donne lieu à des formules 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 reflètent ce qui a effectivement été 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 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 supprimés ne réapparaissent pas).

Given/When/Then, 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 et 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 devrait être divisée, et les critères 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 sur les critères d’acceptation.

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

Voici le déroulement d’une histoire réelle, à 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 du raffinement 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 d’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 lors de la création ultérieure d’un compte.

É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.

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 de « user story » ?

« 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 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 champs 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 « Étant donné / Quand / Alors » 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.

Les critères d’acceptation doivent-ils suivre la structure « Given/When/Then » ou prendre la forme d’une liste de contrôle ?

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’une « 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 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 projets de recherche ponctuels génère des phrases qui ajoutent des formalités 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 » ?: la raison d’être du modèle, les trois « C » et le principe INVEST.
• Exemples d’histoires d’utilisateurs : seize histoires commenté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é de mesure utilisée pour évaluer la taille d’une carte une fois terminée.