Contrairement à une idée largement répandue, Scrum ne définit pas de modèle officiel pour écrire une User Story. Au fil des années, les équipes ont adapté leur manière de formuler les besoins en fonction de leur contexte, de leur produit et de leur façon de collaborer.
Cet article propose de faire le tour des principales approches afin de comprendre non seulement comment elles s’écrivent, mais surtout pourquoi elles existent.
1. La User Story n’a jamais eu de format officiel
C’est probablement ma première surprise.
Le Guide Scrum ne parle jamais du format (« En tant que… Je veux… Afin de…« ). Il ne définit pas non plus ce qu’est une User Story.
Le guide décrit simplement le Product Backlog comme une liste ordonnée d’éléments représentant le travail nécessaire pour améliorer le produit. Ces éléments peuvent prendre différentes formes : fonctionnalités, corrections de bugs, améliorations techniques, recherches, expérimentations, etc.
La User Story est donc une pratique, pas une règle de Scrum, et change donc avec les pratiques, équipes et produits.
Son origine remonteraiy à Extreme Programming (XP), où Ron Jeffries la résumait par la règle des 3C.
La user-story XP (Extreme Programming) :
- Format card : une carte contenant quelques mots, pour encourager la synthèse
- Conversation : retrace les échanges entre les personnes concernées
- Confirmation : les critères permettant de vérifier que le besoin est satisfait sont indiqués
Autrement dit, la carte n’était jamais censée contenir toute la spécification. Elle servait avant tout à déclencher une conversation.
Au fil des années, d’autres approches sont apparues : Lean, Product Discovery, Design Thinking, SAFe, Kanban… Chacune a fait évoluer la manière d’exprimer un besoin.
C’est pourquoi il existe aujourd’hui une grande diversité de formats. Ils ne sont pas concurrents ; ils répondent simplement à des situations différentes.
2. Les grandes familles de User Stories
Il existe des dizaines de variantes. Ce tableau m’aide à comprendre dans quel contexte chacune apporte de sa valeur.
| Famille | Format | Quand l’utiliser ? | Pourquoi existe-t-il ? | Avantages | Limites |
|---|
| User Story classique | En tant que [persona], je veux [objectif], afin de [bénéfice/valeur] | Fonctionnalités orientées utilisateur | Garder l’utilisateur au centre de la réflexion | Simple, largement connue, favorise les échanges | Le persona peut être artificiel ou peu utile |
| Job Story | Lorsque [situation], je veux [motivation], afin de [résultat attendu] | Lorsque le contexte d’utilisation est plus important que le profil utilisateur | Comprendre ce qui déclenche réellement le besoin | Très orientée usage réel, utile en Product Discovery | Moins intuitive pour les équipes habituées aux User Stories classiques |
| Story technique | Mettre à jour… / Migrer… / Remplacer… | Dette technique, architecture, infrastructure | Rendre visibles les travaux techniques indispensables | Intègre la technique dans le backlog produit | N’exprime pas directement une valeur utilisateur |
| Spike Story | Explorer… / Évaluer… / Comparer… | Lorsque l’équipe manque d’informations | Réduire les incertitudes avant le développement | Limite les risques et éclaire les décisions | Ne produit généralement pas de fonctionnalité livrable |
| Enabler Story | Préparer… / Mettre en place… / Créer les fondations… | Préparer une évolution future | Construire les capacités nécessaires avant une fonctionnalité | Anticipe les besoins techniques ou organisationnels | Valeur métier parfois difficile à percevoir |
| Bug Story | Corriger… / Résoudre… | Corriger un dysfonctionnement | Intégrer les anomalies dans le backlog | Facilite la priorisation avec les autres travaux | Tous les bugs ne nécessitent pas une Story dédiée |
| Workflow Story | Permettre à [acteur métier] de [réaliser une étape] | Applications métier, processus internes | Décrire un processus métier | Très adaptée aux logiciels d’entreprise | Peu pertinente pour des produits grand public |
| Opportunity Story | Les utilisateurs ont des difficultés à… ou Comment pourrions-nous aider… ? | Product Discovery | Décrire un problème avant de chercher une solution | Encourage l’exploration et évite de figer une solution | Demande une certaine maturité produit |
Ce tableau montre une chose essentielle : le choix d’un format dépend davantage du problème à résoudre que de Scrum lui-même.
Une équipe qui développe une plateforme SaaS, un logiciel métier ou un produit grand public ne rencontrera pas les mêmes besoins, elles n’utilisent donc pas exactement les mêmes formulations.
En réalité, il est rare qu’un Product Backlog ne contienne qu’un seul type de User Story. Une Story classique peut côtoyer un Spike, un bug ou une amélioration technique sans que cela pose le moindre problème.
L’objectif n’est pas d’uniformiser les intitulés, mais de rendre le backlog compréhensible et utile pour tous les acteurs du produit.
3. Qu’est ce qui compte réellement ?
À force de parler de modèles, il est facile d’oublier l’essentiel.
Une User Story n’a jamais eu vocation à devenir une mini-spécification fonctionnelle. Son rôle est plutôt de faciliter les échanges entre les personnes qui conçoivent, développent et utilisent le produit.
Qu’elle commence par « En tant que… », « Lorsque… » ou qu’elle ne suive aucun modèle particulier importe finalement assez peu.
Les questions les plus importantes sont :
- Le besoin est-il compris par toute l’équipe ?
- La valeur recherchée est-elle clairement identifiée ?
- Les critères d’acceptation permettent-ils de savoir quand le travail sera terminé ?
- La Story est-elle suffisamment petite pour être réalisée dans un délai raisonnable ?
- Favorise-t-elle les discussions plutôt que de les remplacer ?
Si la réponse est oui, alors la forme utilisée est la bonne.
En définitive, il n’existe pas une seule bonne manière d’écrire une User Story. Il existe des pratiques adaptées à des contextes différents.
C’est peut-être là la plus grande leçon à retenir : une User Story est un outil au service de la collaboration, pas un exercice de mise en forme. Les équipes les plus efficaces ne sont pas celles qui appliquent un modèle à la lettre, mais celles qui choisissent consciemment la manière de formuler leurs besoins pour mieux construire leur produit.
