Les User Stories sont devenues le format dominant pour décrire les éléments du Product Backlog en agile et en Scrum. Pourtant, le Scrum Guide ne les rend pas obligatoires. Ce guide est conçu pour devenir la référence francophone sur la User Story : définition, anatomie, critères INVEST, critères d'acceptation, découpage, cycle de vie, erreurs fréquentes et questions PSM I.
Définition d'une User Story
Une User Story (ou « histoire utilisateur ») est une description courte d'une fonctionnalité, formulée du point de vue de la personne qui en bénéficie. Elle a été popularisée par Kent Beck dans le cadre de l'Extreme Programming (XP) à la fin des années 1990 et formalisée par Mike Cohn dans User Stories Applied (2004).
La règle des « 3 C » de Ron Jeffries résume parfaitement son esprit :
- Card — une carte courte qui exprime l'intention.
- Conversation — une discussion entre PO, Developers et stakeholders pour préciser le besoin.
- Confirmation — des critères d'acceptation pour valider la story.
Définition selon le Scrum Guide
Le Scrum Guide 2020 ne parle jamais de User Stories. Il parle de Product Backlog Item (PBI) :
« Le Product Backlog est une liste émergente et ordonnée de ce qui est nécessaire pour améliorer le produit. C'est l'unique source du travail entrepris par le Scrum Team. »
Autrement dit : une User Story est un Product Backlog Item, mais un PBI n'est pas forcément une User Story.
Pourquoi Scrum ne rend pas les User Stories obligatoires
Scrum est un cadre minimaliste : il définit les rôles, les événements et les artefacts, mais laisse au Scrum Team le choix des techniques. Imposer un format de PBI serait contraire à la nature empirique et auto-gérée de Scrum.
Pourtant, les User Stories sont devenues un standard de facto car elles :
- centrent la conversation sur l'utilisateur, pas la solution ;
- obligent à exprimer la valeur recherchée ;
- sont assez courtes pour rester négociables jusqu'au Sprint ;
- se prêtent bien aux critères d'acceptation et aux tests.
Anatomie d'une User Story
Le format le plus utilisé est celui popularisé par Mike Cohn :
En tant que [rôle], je veux [action / fonctionnalité], afin de [valeur].
Chaque partie a un rôle précis :
- Rôle — pour qui ? un persona, pas « l'utilisateur » générique.
- Action — quoi ? un besoin, pas une solution technique.
- Valeur — pourquoi ? la motivation business ou utilisateur.
Exemples détaillés
Voici plusieurs exemples concrets, dans des contextes variés.
E-commerce
En tant que client e-commerce, je veux filtrer les produits par prix, afin de trouver rapidement ce qui rentre dans mon budget.
- Critères d'acceptation : slider min/max ; mise à jour de la liste sans rechargement ; persistance du filtre dans l'URL.
Banque
En tant que client de la banque, je veux activer/désactiver ma carte depuis l'application mobile, afin de la sécuriser instantanément en cas de perte.
Assurance
En tant qu'assuré, je veux déclarer un sinistre auto en moins de 5 minutes depuis mon mobile, afin d'être indemnisé plus vite.
Application mobile
En tant qu'utilisateur premium, je veux recevoir une notification push quand un nouveau contenu est publié, afin de ne rien manquer.
SaaS B2B
En tant qu'administrateur du compte, je veux inviter de nouveaux utilisateurs par email, afin d'élargir mon équipe sans support.
Mauvaise vs excellente User Story
| Critère | ❌ Mauvaise | ✅ Excellente |
|---|---|---|
| Format | « Ajouter un bouton export » | « En tant que comptable, je veux exporter les factures du mois au format Excel, afin de les transmettre à mon expert-comptable. » |
| Valeur | Non exprimée | Explicite (« afin de les transmettre ») |
| Taille | « Refondre tout le module facturation » | Livrable en un Sprint |
| Critères d'acceptation | Aucun | Format Excel valide · colonnes définies · plage de dates filtrable |
| Testabilité | Vague | Vérifiable objectivement |
Qui écrit, raffine et estime les User Stories
| Activité | Qui est responsable | Qui contribue |
|---|---|---|
| Proposer une User Story | N'importe qui (PO, Dev, stakeholder, utilisateur) | Tout le Scrum Team |
| Ordonner | Product Owner (seul décisionnaire) | — |
| Raffiner | Scrum Team (collaboration) | Stakeholders ponctuels |
| Critères d'acceptation | Product Owner (quoi) | Developers (comment vérifier) |
| Estimation | Developers (seuls) | PO clarifie, Scrum Master facilite |
| Déclarer Done | Developers (selon DoD) | PO accepte la valeur livrée |
Les critères INVEST
Proposé par Bill Wake en 2003, l'acronyme INVEST aide à évaluer la qualité d'une User Story.
| Lettre | Critère | Définition | Erreur fréquente |
|---|---|---|---|
| I | Independent | Indépendante des autres stories autant que possible | Stories en chaîne qui doivent toutes être livrées ensemble |
| N | Negotiable | Négociable jusqu'au début du Sprint | Story rédigée comme un contrat figé |
| V | Valuable | Apporte de la valeur à l'utilisateur ou au business | Story technique sans valeur exprimée |
| E | Estimable | Suffisamment claire pour être estimée | Story floue : « Améliorer la performance » |
| S | Small | Petite, livrable dans un Sprint (idéalement quelques jours) | Epic déguisé en User Story |
| T | Testable | Critères d'acceptation vérifiables | Aucun moyen objectif de dire si c'est Done |
Critères d'acceptation : Given / When / Then
Les critères d'acceptation définissent les conditions qui rendent la story acceptable. Le format Given / When / Then (issu de BDD — Behaviour Driven Development) est le plus répandu.
Given [contexte initial]
When [action de l'utilisateur ou événement]
Then [résultat attendu]
Exemple — Filtre prix e-commerce
- Given que je suis sur la page « Catalogue » avec 120 produits affichés,
- When je règle le filtre prix entre 20 € et 50 €,
- Then la liste se met à jour sans rechargement et n'affiche que les produits dans cette plage.
Exemple — Activation carte bancaire
- Given que je suis connecté à l'application mobile,
- When je désactive ma carte depuis l'écran « Sécurité »,
- Then toute transaction est refusée dans les 10 secondes suivantes.
User Story vs Epic vs Task
| Epic | User Story | Task | |
|---|---|---|---|
| Niveau | Très large | Fonctionnalité utilisateur | Travail technique |
| Durée | Plusieurs Sprints | 1 Sprint maximum | Quelques heures à 1 jour |
| Point de vue | Utilisateur (très haut niveau) | Utilisateur (concret) | Developer |
| Apporte de la valeur ? | Oui, indirectement | Oui, directement | Pas seule |
| Présent dans le Product Backlog ? | Oui (à découper) | Oui | Non — vit dans le Sprint Backlog |
| Exemple | Refondre le tunnel de paiement | Payer en Apple Pay | Ajouter le SDK Apple Pay |
User Story vs Product Backlog Item
Un Product Backlog Item est n'importe quoi qui peut entrer dans le Product Backlog : User Story, bug, story technique, spike, exigence non fonctionnelle… La User Story est une forme de PBI, particulièrement adaptée aux fonctionnalités orientées utilisateur.
Voir aussi notre guide dédié aux Product Backlog Items pour les autres formats possibles.
User Story Mapping
Le User Story Mapping, formalisé par Jeff Patton en 2014, est une technique de visualisation du Product Backlog en deux dimensions :
- Axe horizontal — le parcours utilisateur (le « backbone ») : Découvrir → Choisir → Acheter → Suivre.
- Axe vertical — la priorité et les releases : MVP en haut, améliorations en dessous.
Le Story Mapping facilite la construction d'un MVP cohérent (chaque étape du parcours est couverte) plutôt qu'un MVP « tronqué » livrant une seule étape complète. Un guide dédié « User Story Mapping » viendra bientôt approfondir cette technique.
Comment découper une grosse User Story
Lors du refinement, les stories trop grosses doivent être découpées. Techniques classiques :
- Par workflow — créer le compte, puis activer, puis se connecter.
- Par règle métier — paiement standard d'abord, promotions ensuite.
- Par variation de données — d'abord les particuliers, puis les entreprises.
- Par interface — d'abord la version desktop, puis la mobile.
- Par chemin — d'abord le happy path, puis les cas d'erreur.
- Par opération CRUD — Read d'abord, Create ensuite, Update et Delete plus tard.
Cycle de vie pendant un Sprint
- 1. Idée
- 2. Product Backlog
- 3. Refinement
- 4. Sprint Planning
- 5. Développement
- 6. Tests
- 7. Done
- Idée — proposée par n'importe qui dans l'organisation.
- Product Backlog — le PO l'ordonne selon la valeur.
- Refinement — clarifier, découper, estimer, ajouter critères.
- Sprint Planning — sélectionnée par les Developers pour le Sprint Goal.
- Développement — réalisée pendant le Sprint, suivie au Daily Scrum.
- Tests — validation contre les critères d'acceptation et la Definition of Done.
- Done — incluse dans l'Increment présenté en Sprint Review.
Les 10 erreurs les plus fréquentes
- Écrire une solution au lieu d'un besoin (« je veux un bouton… »).
- Oublier le « afin de » — la valeur disparaît.
- Utiliser « l'utilisateur » générique au lieu d'un persona.
- Faire de la User Story un contrat figé (plus de conversation).
- Inclure plusieurs besoins dans une seule story (S d'INVEST violé).
- Pas de critères d'acceptation (T violé).
- Confondre critères d'acceptation et Definition of Done.
- Laisser le PO estimer seul.
- Estimer en jours-hommes au lieu de complexité relative (Story Points).
- Ajouter des stories en cours de Sprint sans renégocier avec les Developers.
Pièges du PSM I
Questions type examen PSM I
Ressources et maillage
Pages à venir dans ce cluster : User Story Example, User Story Template, critères INVEST détaillés, Acceptance Criteria, Story Mapping, Epic vs User Story, User Story vs Task, User Story vs Use Case, Story Points, Planning Poker, Velocity.