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é. La technique de référence pour estimer collectivement est le planning poker : un vote simultané qui évite l'effet d'ancrage et révèle les désaccords de compréhension.
User stories et épics : quelle relation ?
Dans une hiérarchie backlog bien structurée, les épics regroupent des user stories partageant le même objectif fonctionnel. Une épic "Authentification" peut contenir une dizaine de stories : inscription, connexion, récupération de mot de passe, authentification à deux facteurs, etc.
La granularité : trouver le bon niveau
Le piège courant est de créer des épics trop petites (quasi-stories) ou des stories trop grandes (quasi-épics). Une heuristique utile : si une user story ne peut pas être complétée en moins de 3 jours par un développeur, elle mérite d'être découpée. Si une épic peut être terminée en un seul sprint, c'est probablement une grosse story.
Certains frameworks ajoutent un niveau supplémentaire au-dessus des épics : les thèmes ou super-épics. Cette structure à trois niveaux : Super Épics → Épics → User Stories : reflète la réalité des backlogs produit de moyenne et grande taille.
Le backlog refinement : garder le sommet prêt
Le backlog refinement (ou grooming) est le processus continu qui transforme des idées vagues en stories prêtes à entrer en sprint. Ce travail ne se fait pas en sprint planning : il s'anticipe. L'objectif : maintenir en permanence un "sommet" du backlog composé de stories INVEST-compliant, estimées et dotées de critères d'acceptation clairs.
Sans ce travail préparatoire régulier, le sprint planning devient une réunion de clarification improvisée : inefficace et frustrante pour tout le monde.
Quand une user story est-elle prête à entrer en sprint ?
La Definition of Ready (DoR) est le pendant côté entrée de la Definition of Done côté sortie. Les conditions de sortie sont vérifiées en sprint review. Elle définit les conditions minimales qu'une story doit remplir avant d'être sélectionnée en sprint planning :
- Rédigée au format standard (En tant que / Je veux / Afin de)
- Critères d'acceptation écrits et validés par le PO
- Estimée (ou jugée estimable) par l'équipe
- Dépendances identifiées et non bloquantes
- Maquette ou spécification disponible si nécessaire
Ces critères constituent une convention d'équipe, pas une règle du Scrum Guide. Si une story reste trop floue, l'équipe peut la clarifier, la découper ou différer sa sélection selon le risque qu'elle ferait peser sur le Sprint Goal.
User stories dans Manifst
Dans Manifst, les tickets s'inscrivent dans une hiérarchie à trois niveaux : Super Épics → Épics → Tickets. Chaque élément porte ses critères d'acceptation, son estimation en points, son assignation, son type et son statut.
La bibliothèque du plan Team propose plus de 70 modèles de user stories par domaine métier. Les fonctions IA peuvent générer des critères, contrôler la qualité d'une story, proposer des sous-tâches ou une estimation ; elles utilisent les crédits du compte.
Le Planning Poker fonctionne dans une session collaborative en temps réel au niveau du projet. Le résultat choisi est reporté sur le ticket et devient ensuite visible dans le sprint planning. Découvrir le backlog Manifst.
Essayez Manifst gratuitement : 1 projet, 5 membres, sans carte bancaire ; budget EVM inclus.