Écrire des user stories claires
Partager
En bref. Une user story exprime un besoin en une phrase, du point de vue de l'utilisateur : « en tant que [rôle], je veux [action], afin de [bénéfice] ». Elle ne décrit pas une fonction technique, mais un pourquoi. Une bonne story est courte, centrée sur un utilisateur réel, et accompagnée d'un critère qui dit quand elle est réussie — pas un cahier des charges déguisé.
Chez Edelw'ice, le glacier artisanal lausannois fondé par Heidi en 1983, l'équipe monte en 2010 son site de vente en ligne. Elle bute sur une ligne du backlog produit — la liste, ordonnée par valeur, de tout ce qui reste à construire sur le produit : « créer un espace compte ». Pour l'un, c'est un formulaire ; pour l'autre, un historique de commandes ; pour un troisième, une liste de favoris. Nina, l'UX designer, et Lexie, celle des deux analystes qui va voir sur le terrain, tranchent d'un geste : « on n'écrit pas la fonction, on écrit qui en a besoin et pourquoi ». La discussion s'arrête là.
Si tu as déjà vu une équipe passer une heure sur ce qu'une ligne « veut dire », tu as vu l'absence de user story.
Pourquoi une demande floue coûte-t-elle si cher ?
Parce qu'une fonction sans utilisateur ni bénéfice se comprend de dix façons — et se construit donc mal. « Ajouter un compte » ne dit ni pour qui, ni pour quoi. Chacun comble le vide avec sa propre idée, et on découvre le malentendu une fois le travail fait.
Lexie part toujours de l'utilisateur : « qui, concrètement, et pour gagner quoi ? ». Abby, elle, ajoute le garde-fou : « comment saura-t-on que c'est réussi ? ». L'une ouvre le besoin, l'autre le rend vérifiable.
Qu'est-ce qu'une user story, concrètement ?
La user story — le récit utilisateur — est un besoin exprimé en une phrase, du point de vue de celui qui s'en sert : « en tant que [rôle], je veux [action], afin de [bénéfice] ». Le dernier morceau, le afin de, est le plus important : c'est lui qui porte le pourquoi.
La règle d'or : si le "afin de" est vide, la story ne sert à rien. Une action sans bénéfice n'est pas un besoin, c'est une solution qu'on s'impose.
Le réflexe de Lexie. « Une story part d'une personne, pas d'un bouton. » Elle nomme l'utilisateur avant l'action.
Le réflexe d'Abby. « Une story sans critère n'est pas finie. » Elle ajoute la condition observable qui dira : c'est réussi.
À quoi ça ressemble, chez Edelw'ice
La ligne « créer un espace compte » devient une story nette : « en tant que cliente fidèle, je veux retrouver mes commandes passées, afin de recommander mes parfums préférés en deux clics ». Tout change : on sait pour qui (la cliente fidèle), pour quoi (recommander vite), et comment vérifier (retrouver et recommander en deux clics). Nina peut concevoir, l'équipe peut construire — et la story tient sur une ligne.
La même logique, hors du numérique
Un brief de recrutement gagne à la même formule : « en tant qu'équipe support, nous voulons une personne qui gère les retours clients, afin de libérer deux heures par jour ». Un besoin de réunion, de matériel, de service : dès qu'on nomme qui et pour quoi, la demande devient claire et discutable. La user story est d'abord une façon de formuler un besoin.
Écrire tes user stories en trois gestes
- Pars d'un utilisateur réel et écris « en tant que [rôle], je veux [action], afin de [bénéfice] ».
- Vérifie le bénéfice. Si le « afin de » sonne creux, le besoin n'est pas compris — reformule.
- Ajoute un critère d'acceptation : la condition observable, la petite phrase qui dit quand la story est réussie.
Ces trois gestes ne remplacent pas la conversation avec l'équipe — c'est même leur but : ouvrir la bonne discussion, pas la clore par un document.
Le deck BADASS rassemble les récits utilisateurs et les autres techniques sur des cartes : une vue d'ensemble, et un moyen de se rappeler laquelle sortir le jour venu. Le déroulé complet sur un cas réel — critères d'acceptation, découpage, cas limites, arbitrages, chiffres — c'est l'eBook consacré à la technique.
Pour aller plus loin (le référentiel). Dans le BABOK®, les récits utilisateurs — User Stories, §10.48 — sont mobilisés par la tâche « Spécifier et modéliser les exigences » (7.1), dans le domaine Analyse des exigences et définition de la conception (ou du design). Ils servent aussi à « Maintenir les exigences » (5.2), dans la gestion du cycle de vie : une technique n'appartient pas à un domaine, ce sont les tâches qui l'appellent qui en ont un.
Questions fréquentes
Qu'est-ce qu'une user story ?
Une user story (récit utilisateur) est un besoin exprimé en une phrase du point de vue de l'utilisateur : « en tant que [rôle], je veux [action], afin de [bénéfice] ». Elle dit le pourquoi, pas seulement le quoi.
Comment écrire une bonne user story ?
Pars d'un utilisateur réel et d'un bénéfice concret, garde une phrase, et ajoute un critère d'acceptation — la condition observable qui dit quand c'est réussi. Si la story tient sur une ligne et se teste, elle est bonne.
Quelle différence entre une user story et une spécification ?
La spécification décrit comment construire ; la user story décrit qui a besoin de quoi et pourquoi. La story ouvre une conversation ; elle ne la remplace pas par un document de dix pages.
User story ou cas d'utilisation ?
La user story est courte et centrée sur un besoin ; le cas d'utilisation détaille un scénario d'interaction complet, étape par étape. On choisit selon le niveau de détail nécessaire.
Articles liés : 5 techniques pour un Product Owner qui priorise mieux · Gérer son backlog sans se noyer · Quelle technique de BA pour quel problème
