Une user story (ou récit utilisateur) est la pierre angulaire du développement Scrum. C'est une description courte, formulée du point de vue de l'utilisateur final, d'une fonctionnalité qu'il souhaite voir dans le produit. Derrière cette définition simple se cache pourtant une discipline que beaucoup d'équipes peinent à maîtriser.
Le format standard d'une user story
La formulation classique, introduite par Mike Cohn, suit ce patron :
En tant que [type d'utilisateur], je veux [objectif], afin de [bénéfice].
Exemple concret :
En tant que chef de projet, je veux voir la vélocité de l'équipe sur les 5 derniers sprints, afin de prévoir la capacité du prochain sprint avec précision.
Ce format force l'auteur à identifier qui bénéficie de la fonctionnalité, quoi est demandé, et pourquoi c'est utile. Le "pourquoi" est souvent omis — c'est pourtant la partie la plus importante.
Les critères d'acceptation
Une user story sans critères d'acceptation est une invitation au désaccord. Les critères d'acceptation définissent précisément ce que signifie "terminé" pour cette story. Ils prennent souvent la forme de scénarios Gherkin :
- Étant donné (Given) — le contexte initial
- Quand (When) — l'action effectuée
- Alors (Then) — le résultat attendu
Exemple pour la story précédente :
- Étant donné que je suis connecté en tant que chef de projet
- Quand j'accède au dashboard du projet
- Alors je vois un graphique de vélocité affichant les 5 derniers sprints
- Et chaque point représente la somme des story points complétés
Le principe INVEST
Bill Wake a défini six qualités que doit posséder une bonne user story, résumées par l'acronyme INVEST :
- Indépendante — livrable sans dépendre d'une autre story
- Négociable — pas un contrat figé, mais une base de discussion
- Valuable (de valeur) — apporte quelque chose à l'utilisateur ou au métier
- Estimable — l'équipe peut l'estimer en story points
- Small (petite) — réalisable en un sprint
- Testable — on peut vérifier qu'elle est terminée
Les erreurs courantes
1. Écrire des tâches techniques déguisées
"Migrer la base de données vers PostgreSQL" n'est pas une user story. Personne ne demande une migration de BDD pour son usage propre. Reformulez en termes de valeur utilisateur, ou considérez que c'est une tâche technique à estimer différemment.
2. Des stories trop grandes (epics non découpées)
"En tant qu'utilisateur, je veux gérer mon profil" est trop vaste. Découpez en stories atomiques : changer son mot de passe, modifier son avatar, mettre à jour ses informations de facturation — chacune livrable séparément.
3. Omettre le bénéfice
"En tant qu'admin, je veux exporter les données" laisse l'équipe dans le flou. Pour quoi faire ? Pour un rapport comptable mensuel ? Pour migrer vers un autre outil ? Le "afin de" oriente les choix d'implémentation.
Taille et estimation en story points
Les story points mesurent la complexité relative, pas la durée. Une story de 8 points est environ deux fois plus complexe qu'une de 4 points — mais sa durée réelle dépend de qui la traite et des imprévus. La suite de Fibonacci (1, 2, 3, 5, 8, 13, 21) est la plus utilisée car elle force les équipes à reconnaître les grandes incertitudes.
Une story dépassant 13 points mérite presque toujours d'être découpée. Au-delà, l'estimation perd tout sens et le risque de débordement est élevé.
User stories dans Manifst
Dans Manifst, les user stories s'inscrivent dans une hiérarchie à trois niveaux : Super Épics → Épics → User Stories. Chaque story porte ses critères d'acceptation, son estimation en points, son assignation et son statut. La bibliothèque intégrée propose plus de 70 stories pré-rédigées par domaine métier, prêtes à être adaptées à votre contexte.