Une user story est une description courte d’un besoin, formulée du point de vue de la personne qui utilisera l’application : « En tant que [rôle], je veux [action] afin de [bénéfice] ». Elle ne se suffit jamais à elle-même : ce sont ses critères d’acceptation, des exemples concrets et vérifiables, qui disent quand la fonctionnalité est réellement terminée. Une bonne story passe la grille INVEST, et ses critères s’écrivent idéalement sous la forme « Étant donné / Quand / Alors ». C’est l’équipe métier qui détient les règles : c’est donc elle qui doit écrire ou valider ces critères.
Ce guide s’adresse aux directeurs métier, chefs de service et référents qui participent à un projet d’application sans être développeurs. Il explique comment écrire des stories utiles, comment les vérifier et comment éviter les malentendus qui coûtent des sprints entiers.
Qu’est-ce qu’une user story, et à quoi sert-elle vraiment ?
Une user story n’est pas une spécification. C’est un point de départ pour une conversation. Ron Jeffries, l’un des fondateurs de l’Extreme Programming, la résume en trois « C » dans un article de 2001, Card, Conversation, Confirmation :
- La carte : une phrase qui identifie le besoin et sert de repère pour la planification.
- La conversation : l’échange entre le métier et l’équipe de développement, qui précise les règles, les exceptions, les cas limites.
- La confirmation : les tests d’acceptation, qui prouvent que ce qui a été livré correspond à ce qui était attendu.
Beaucoup de projets ne gardent que la carte. On se retrouve alors avec un backlog rempli de phrases du type « En tant qu’utilisateur, je veux exporter les données », que chacun interprète différemment. Le développeur livre un export CSV, le contrôleur de gestion attendait un fichier Excel avec ses sous-totaux, et l’écart n’apparaît qu’à la démonstration.
Les trois parties de la phrase
- « En tant que » : un rôle précis, pas « un utilisateur ». Un chef d’atelier, une assistante ADV ou un technicien terrain n’ont ni les mêmes droits ni les mêmes contraintes.
- « Je veux » : une action observable, décrite dans le vocabulaire du métier, sans solution technique imposée.
- « Afin de » : le bénéfice. C’est la partie la plus souvent oubliée, et la plus utile : elle permet de proposer une meilleure solution que celle imaginée au départ, et de prioriser.
Exemple pour une entreprise de négoce : « En tant que commercial sédentaire, je veux voir l’encours et le retard de paiement d’un client depuis sa fiche afin de ne pas accepter une commande qui sera bloquée par la comptabilité. »
Comment savoir si une user story est bien écrite ? La grille INVEST
En 2003, Bill Wake a proposé un moyen mnémotechnique devenu la référence pour juger une story : INVEST. Chaque lettre correspond à une question simple que l’équipe métier peut se poser.
| Critère | Question à se poser | Signal d’alerte |
|---|---|---|
| Indépendante | Peut-on la développer sans attendre une autre story ? | « Cette story n’a de sens qu’avec les trois suivantes » |
| Négociable | Le besoin est-il décrit, plutôt qu’une solution figée ? | La story impose un écran, un bouton, une technologie |
| Valeur | Un utilisateur ou l’entreprise y gagne-t-il quelque chose ? | Story purement technique sans bénéfice visible |
| Estimable | L’équipe peut-elle en évaluer l’effort ? | Trop d’inconnues, règles de gestion non connues |
| Small (petite) | Tient-elle confortablement dans un sprint ? | Plusieurs semaines de travail, des dizaines de règles |
| Testable | Sait-on comment vérifier qu’elle est terminée ? | « L’écran doit être simple et rapide » |
Bill Wake précise qu’une story représente au plus quelques semaines-personne de travail, et que beaucoup d’équipes visent quelques jours. Plus une story est petite, plus son estimation est fiable et plus vite le métier peut la voir fonctionner.
Découper une story trop grosse
Une story trop grosse s’appelle souvent une épopée (epic). Pour la découper sans perdre la valeur, plusieurs axes fonctionnent bien :
- Par étape du processus : saisir la demande, la valider, la transmettre.
- Par règle de gestion : d’abord le cas standard, ensuite les remises, ensuite les clients export.
- Par type de données : les clients actifs d’abord, les prospects ensuite.
- Par niveau de confort : une version simple qui fonctionne, puis les filtres, les raccourcis et les exports.
- Par rôle : ce que voit le commercial, puis ce que voit son responsable.
Le piège à éviter est le découpage par couche technique (« la base de données », puis « l’écran ») : aucune des deux moitiés n’apporte de valeur seule, et le métier ne peut rien vérifier avant la fin.
Que sont les critères d’acceptation ?
Les critères d’acceptation sont les conditions qu’une fonctionnalité doit remplir pour être acceptée par le responsable produit. Ils transforment une intention en contrat vérifiable. Sans eux, la recette devient un débat d’opinions ; avec eux, elle devient une vérification.
Un bon critère d’acceptation est :
- observable : on peut constater le résultat à l’écran, dans un fichier ou dans un e-mail ;
- non ambigu : deux personnes qui le lisent arrivent au même verdict ;
- centré sur le comportement, pas sur l’implémentation ;
- concret : il contient de vraies valeurs, de vrais exemples.
Comparez « le calcul de la remise doit être correct » avec « un client de catégorie B qui commande 120 unités obtient 5 % de remise sur la ligne ». Le second peut être testé par n’importe qui, y compris par un nouvel arrivant.
Critères d’acceptation et définition de terminé
On confond souvent les deux. Les critères d’acceptation sont propres à chaque story. La définition de terminé, elle, est commune à toutes : le Scrum Guide la décrit comme la description formelle de l’état de l’incrément lorsqu’il atteint les exigences de qualité du produit. Elle couvre par exemple la relecture du code, les tests automatisés, le déploiement sur l’environnement de recette et la mise à jour de la documentation.
Comment écrire des critères avec Étant donné / Quand / Alors ?
Le format Étant donné / Quand / Alors (Given / When / Then) a été développé par Dan North et Chris Matts dans le cadre du Behavior-Driven Development, comme le rappelle Martin Fowler. Il découpe chaque exemple en trois temps :
- Étant donné : la situation de départ (les données, le contexte, le rôle connecté) ;
- Quand : l’action ou l’événement ;
- Alors : le résultat attendu, observable.
Reprenons la story du commercial sédentaire :
# language: fr
Fonctionnalité: Encours client visible depuis la fiche
Scénario: Client en retard de paiement
Étant donné un client dont une facture est échue depuis 45 jours
Quand le commercial ouvre la fiche du client
Alors un bandeau signale le retard de paiement
Et le montant échu est affiché
Scénario: Client à jour
Étant donné un client sans facture échue
Quand le commercial ouvre la fiche du client
Alors aucun bandeau d’alerte n’est affiché
Ce texte se lit sans formation. C’est le langage Gherkin, utilisé par l’outil Cucumber : sa documentation de référence indique qu’il est traduit dans plus de 70 langues, dont le français, grâce à l’en-tête # language: fr. L’équipe de développement peut ensuite automatiser ces scénarios, qui deviennent des tests exécutés à chaque livraison.
Les bonnes pratiques Gherkin
- Un scénario, un comportement. Si le scénario contient deux « Quand », il en cache deux.
- Trois à cinq étapes. C’est la recommandation de Cucumber pour que l’exemple reste une documentation lisible.
- Le vocabulaire du métier. « Le commercial valide le devis », pas « l’utilisateur clique sur le bouton id=btn-submit ».
- Des exemples aux limites. 119 et 120 unités pour un seuil à 120, une date d’échéance tombant un jour férié, un client sans SIREN.
- Les tableaux d’exemples (Plan du scénario) quand la même règle s’applique à plusieurs valeurs : une ligne par catégorie de client, par exemple.
Quel rôle pour l’équipe métier, concrètement ?
Le développeur sait construire ; le métier sait ce qui se passe vraiment : la remise exceptionnelle accordée à un client historique, le bon de livraison ressaisi parce que le transporteur ne lit pas le format standard, le contrôle que fait la comptable à chaque fin de mois. Ces cas particuliers sont précisément ceux qui font échouer une application lorsqu’ils sont découverts en production.
Une pratique efficace consiste à réunir, pour chaque story importante, trois points de vue pendant vingt à trente minutes : un représentant du métier, un développeur et une personne qui pense aux tests. On liste les règles, puis pour chaque règle un ou deux exemples, puis les questions ouvertes. Les questions sans réponse sont confiées au métier avant le sprint, pas pendant.
Ce travail se prépare dès la phase de cadrage, qui identifie les processus, les rôles et les règles de gestion. Il nourrit ensuite chaque sprint, comme nous l’expliquons dans notre méthode : chaque story terminée est montrée en démonstration et validée au regard de ses critères.
Les erreurs fréquentes, et comment les corriger
| Erreur | Exemple | Correction |
|---|---|---|
| Rôle générique | « En tant qu’utilisateur… » | Nommer le rôle réel : responsable logistique, technicien, client B2B |
| Solution imposée | « Je veux un menu déroulant » | Décrire le besoin : « Je veux choisir un transporteur parmi ceux autorisés pour cette zone » |
| Bénéfice absent | Pas de « afin de » | Se demander ce qui serait perdu si la story n’existait pas |
| Critère vague | « L’export doit être complet » | Lister les colonnes, le format, le tri, le nom du fichier |
| Cas d’erreur oubliés | Seul le cas nominal est décrit | Ajouter les scénarios : donnée manquante, droit insuffisant, doublon |
| Story fourre-tout | Saisie, validation, export et relance dans la même story | Découper par étape du processus |
Un dernier piège, plus organisationnel : écrire toutes les stories détaillées au début du projet. Le besoin évolue dès que les utilisateurs voient les premiers écrans. Mieux vaut un backlog dont seules les stories des deux prochains sprints sont détaillées, et le reste esquissé.
La checklist avant d’envoyer une story en développement
Avant qu’une story entre dans un sprint, vérifiez les points suivants :
- Le rôle est précis et existe vraiment dans l’entreprise.
- Le bénéfice (« afin de ») est explicite et compris par l’équipe.
- La story passe la grille INVEST, en particulier Small et Testable.
- Chaque règle de gestion a au moins un exemple chiffré.
- Les cas d’erreur et les droits d’accès sont couverts.
- Les données de test nécessaires existent ou sont décrites.
- Le métier a relu et validé les critères d’acceptation.
- Les questions ouvertes ont une réponse, ou la story attend.
Ces stories deviennent ensuite la base de la recette de l’application : chaque critère d’acceptation est un cas de test tout trouvé. Si votre projet n’en est qu’au stade de l’expression de besoin, notre modèle de cahier des charges vous aide à poser le contexte et le périmètre avant de découper en stories, et notre page sur les applications web sur mesure détaille comment nous les livrons sprint après sprint.
Vous préparez un projet et souhaitez savoir comment le découper en lots livrables ? Décrivez-le dans notre diagnostic de projet : deux minutes suffisent pour obtenir une première analyse.
