Une user story tient en une phrase: “En tant que [rôle], je veux [action], afin de [bénéfice].” Ce format, popularisé par Mike Cohn dans les années 2000, est devenu un standard de la gestion de projet agile. Sa simplicité est trompeuse, car elle laisse croire que la valeur d’une user story réside dans la phrase elle-même. En réalité, la phrase n’est qu’un point de départ.
Les trois C: Card, Conversation, Confirmation
Ron Jeffries, l’un des signataires du Manifeste Agile, a formulé un principe que beaucoup d’équipes connaissent mais peu appliquent: une user story repose sur trois composantes indissociables, les trois C.
La Card (carte) est la phrase elle-même, celle qu’on écrit sur un post-it ou dans un outil de backlog. Son rôle n’est pas de tout dire, mais de rappeler de quoi il faut parler.
La Conversation est le moment où l’équipe et les parties prenantes (stakeholders) clarifient ce que la carte ne dit pas. Quelles sont les contraintes? Quels cas particuliers faut-il prendre en compte? Cette conversation peut avoir lieu lors d’un atelier de refinement, d’un échange informel ou d’une réunion de planification, mais elle doit avoir lieu avant que l’équipe commence à travailler.
La Confirmation correspond aux critères d’acceptation: les conditions objectives qui permettront de vérifier que le besoin est satisfait. Sans ces critères, personne ne sait quand le travail est terminé.
Le problème récurrent est que beaucoup d’équipes s’arrêtent à la carte. La story est rédigée, insérée dans le backlog (la liste priorisée des éléments à réaliser), et l’équipe passe à l’exécution sans avoir clarifié les attentes, ce qui produit des allers-retours, des livraisons décalées et des frustrations des deux côtés.
Trois pièges dans la formulation
Même quand la conversation a lieu, elle ne rattrape pas une carte mal formulée. Trois erreurs reviennent constamment.
La première est le rôle vague. “En tant qu’utilisateur” ne dit rien à l’équipe. Un utilisateur, c’est qui? Le responsable logistique qui prépare les expéditions du matin, le stagiaire qui saisit les bons de livraison ou le directeur qui consulte les indicateurs mensuels? “En tant que responsable d’entrepôt travaillant en horaires décalés” dit immédiatement quelque chose sur le contexte d’utilisation et oriente les décisions de l’équipe.
La deuxième est l’action technique au lieu du besoin. “Je veux que le système envoie un email de confirmation” est une spécification déguisée en user story. La vraie question est: que cherche l’utilisateur? Probablement à savoir que sa demande a été prise en compte. La story devrait être: “je veux être informé que ma commande est confirmée”, ce qui laisse l’équipe proposer la solution la plus adaptée.
La troisième est le bénéfice absent. Beaucoup de stories s’arrêtent après l’action, comme si la motivation allait de soi. Prenons un exemple issu de l’événementiel: “En tant qu’organisateur de conférence, je veux visualiser le taux de remplissage des salles.” S’agit-il de réaffecter les intervenants dans des salles plus grandes, de prévoir le catering ou de justifier le budget auprès de la direction? Selon le bénéfice visé, la solution sera radicalement différente.
Critères d’acceptation: ancrer la confirmation
Les critères d’acceptation sont le troisième C en action. Ils décrivent ce qui doit être vrai pour que la story soit considérée comme terminée. Deux formats sont couramment utilisés.
Le format Given/When/Then, issu du Behavior-Driven Development (BDD, une approche qui structure les attentes sous forme de scénarios), convient aux situations contextuelles. Par exemple: “Étant donné qu’un participant s’inscrit après la date limite, quand il soumet le formulaire, alors il reçoit un message l’informant que les inscriptions sont closes et proposant une liste d’attente.”
Le format en liste simple convient aux cas plus directs: le montant ne dépasse pas le plafond autorisé, les justificatifs sont joints, la catégorie de dépense est renseignée. Comme le note l’analyse de Scott Logic, des critères flous ou absents sont l’une des premières sources de retards dans les projets agiles.
INVEST: un filtre de relecture
En 2003, Bill Wake a proposé l’acronyme INVEST comme grille d’évaluation rapide. Selon cette grille, reprise par l’Agile Alliance, une bonne story est Indépendante, Négociable, Valuable (porteuse de valeur pour l’utilisateur final), Estimable, Small (réalisable en quelques jours) et Testable.
INVEST n’est pas une check-list binaire. Il est rare qu’une story satisfasse les six critères simultanément, surtout en début de projet. Mais la grille fonctionne bien comme outil de diagnostic: quand une story pose problème, vérifier laquelle des six dimensions est défaillante aide à identifier la correction nécessaire.
Découper sans perdre la valeur
Le critère “Small” mérite une attention particulière, car une story trop volumineuse, souvent appelée epic (un regroupement de stories liées à un même objectif), est par définition difficile à estimer, à tester et à livrer.
Le réflexe courant est de diviser par composante technique: d’abord la base de données, ensuite l’interface, puis les rapports. Ce découpage horizontal a un défaut majeur: aucune tranche ne livre quelque chose d’utilisable à elle seule. Le découpage vertical, par tranche de valeur utilisateur, est plus efficace. Une story sur la gestion des inscriptions à un séminaire se découpe mieux en: inscrire un participant individuel, inscrire un groupe, gérer les annulations. Chaque tranche traverse toutes les couches nécessaires et livre un résultat complet.
Qui rédige les user stories?
La rédaction des user stories n’est pas la responsabilité exclusive du product owner ou de l’analyste métier. Les parties prenantes qui expriment un besoin, les membres de l’équipe qui observent un problème récurrent, le chef de projet qui synthétise les retours d’un atelier: tous peuvent initier une story.
Ce qui distingue une bonne pratique d’une mauvaise n’est pas l’auteur de la carte, mais l’existence de la conversation qui suit. Une story parfaitement rédigée par un product owner isolé dans son bureau vaut moins qu’une story maladroite qui a provoqué trente minutes de discussion entre l’équipe et les utilisateurs concernés.