User Stories
Une user story est un énoncé bref d'un besoin qui apporte de la valeur à une partie prenante précise: qui a le besoin, ce qu'il veut faire et pourquoi cela compte, en une phrase ou deux. Elle ne dit délibérément pas tout, car elle est une promesse de conversation, complétée par des critères d'acceptation à mesure que l'équipe approche de la livraison. Le BABOK la présente comme une option de représentation des exigences; l'Agile Extension lui donne sa mécanique agile, sa vie sur un backlog, l'heuristique INVEST et le modèle des trois C.
Objectif
Une user story capture un besoin à une granularité légère et invite à l'explorer par la conversation plutôt qu'à le figer dans une spécification. La carte tient en une phrase parce qu'elle n'est pas censée tout porter: elle identifie une partie prenante, ce qu'elle veut faire et la valeur qu'elle en retire, et elle laisse le détail à la discussion qui viendra quand l'équipe s'approchera de la livraison.
Autour de cette unité minuscule s'organise presque toute la conduite d'une livraison itérative. La story est l'unité de priorisation, posée sur un backlog que le chef de produit ordonne, et l'unité que l'équipe dimensionne pour estimer. Ses critères d'acceptation deviennent les cas de test d'acceptation. Elle mesure la valeur livrée, trace les exigences qu'elle recouvre et porte le reporting d'avancement. Le livrable est la story elle-même, la carte et ses critères d'acceptation vivant sur le backlog, parce que sa valeur tient dans la conversation qu'elle déclenche, qu'un document figé étoufferait.
Les deux référentiels ne la cadrent pas de la même façon. Le BABOK traite la story comme un artefact statique de représentation des exigences, un moyen de documentation léger, et prévient qu'elle sert la capture de court terme, non la conservation du savoir à long terme ni une base de référence de gouvernance. L'Agile Extension la traite dynamiquement, comme une promesse de conversation qui vit sur un backlog, et elle fournit les deux heuristiques que le BABOK n'a pas: la qualité, avec INVEST, et la structure, avec les trois C. On prend le premier pour la définition et le cadre documentaire, le second pour la mécanique agile.
Usage
Quand l'utiliser
- Livraison itérative et incrémentale: la valeur part en tranches et les priorités bougent d'une itération à l'autre.
- Un besoin à saisir sans le figer: capter la partie prenante et sa valeur, puis ouvrir la conversation plutôt que geler une spécification.
- Une base d'estimation et de planification: la story est l'unité que l'équipe dimensionne et que l'on ordonne sur le backlog.
- Des tests d'acceptation à ancrer: les critères d'acceptation de la story en sont le point de départ direct.
- Une valeur livrée à mesurer et des exigences à tracer: la story est l'unité qui relie le besoin au livré et au rapport d'avancement.
Quand ne pas l'utiliser
- Exigences réglementaires ou critiques de sécurité: la phrase et sa conversation ne laissent aucune trace durable ni traçable, écrire une spécification d'exigences complète.
- Comportement riche en chemins alternatifs et en exceptions: une ligne ne porte pas les flux, prendre les cas d'utilisation.
- Prestation à prix ferme sans accès continu aux parties prenantes: la conversation promise n'aura pas lieu, arrêter le périmètre par contrat plutôt que de compter sur elle.
Description
La phrase et ses éléments
La forme que tout le monde connaît, « en tant que rôle, je veux objectif, afin de valeur », n'appartient à aucun des deux référentiels. C'est le gabarit dit de Connextra, popularisé par Mike Cohn dans User Stories Applied, et les guides ne font que le relayer. Il tient sa force de sa troisième partie: le afin de, qui nomme la valeur. Les deux premières parties disent qui et quoi, et une exigence classique s'y arrêterait; c'est la valeur qui fait de l'énoncé une story et qui, plus tard, permettra d'arbitrer entre deux façons de la satisfaire.
Le BABOK nomme quatre éléments. Le titre, facultatif, un verbe d'action qui résume la story. L'énoncé de valeur, le cœur, avec le qui, le quoi et le pourquoi. La conversation, la discussion sur le besoin entre les parties prenantes et l'équipe. Et les critères d'acceptation, qui définissent ce qui sera vérifié. Le BABOK les liste; l'Agile Extension les met en tension dans un modèle qui explique pourquoi une carte d'une phrase suffit.
Les trois C: la story est un jeton
Le modèle des trois C revient à Ron Jeffries, qui l'a formulé dans le contexte de l'Extreme Programming. Il tient en trois mots qui commencent tous par C. La Carte est le jeton: juste assez de texte pour identifier et retenir l'exigence. Jeffries en donne le test qui garde les stories petites: si le besoin ne tient pas sur la carte, la carte est trop grosse. La Conversation est l'endroit où l'exigence se transmet réellement, dans le temps, entre les parties prenantes et l'équipe qui livre; la carte ne dit pas tout, délibérément. La Confirmation, ce sont les critères d'acceptation, la base des tests d'acceptation, de régression et exploratoires, qui confirment que l'élément livré satisfait le besoin.
INVEST: tester la qualité d'une story
INVEST est l'acronyme de Bill Wake, publié en 2003, et c'est l'outil avec lequel on juge si une story est utilisable avant de la prendre. Chaque lettre est une propriété que la story doit tenir. Une story qui échoue à l'une d'elles n'est pas une bonne story, quelle que soit la qualité de son écriture.
| Critère | Ce qu'il teste |
|---|---|
| Independent (indépendante) | La story se livre seule, sans dépendre de l'ordre d'une autre, ce qui laisse le chef de produit libre de la prioriser. |
| Negotiable (négociable) | La carte est une invitation à discuter: le détail se règle dans la conversation. |
| Valuable (de valeur) | Elle apporte une valeur perceptible à une partie prenante nommée. C'est le « afin de » qui la porte. |
| Estimable (estimable) | L'équipe peut lui donner une taille. Une story qu'on ne sait pas estimer est trop vague ou trop grosse. |
| Small (petite) | Elle tient dans une itération. L'Agile Extension reformule ce « S » en Sized Appropriately; l'exigence reste la même. |
| Testable (testable) | Ses critères d'acceptation permettent de trancher objectivement si elle est satisfaite. |
Conduire la technique
- Identifier la partie prenante et le besoin
La story appartient à quelqu'un, et ce quelqu'un vient de l'élicitation: d'un atelier, d'un entretien, d'une observation sur le terrain. Les personas aident directement, car le rôle placé en tête de la carte est souvent un persona, et le besoin d'un nouvel arrivant n'est pas celui d'un client de longue date. - Écrire la carte
Dans la forme qui, quoi, pourquoi, en une phrase ou deux, avec un titre facultatif à verbe d'action. On garde la carte courte de propos délibéré, parce que sa brièveté est ce qui force la conversation à avoir lieu. - La poser sur le backlog
Le chef de produit la priorise contre les autres. Le backlog est une file ordonnée qui se réordonne à chaque itération: à chaque tour, le chef de produit reclasse ce qui reste au regard de la valeur attendue et de ce que la dernière livraison a appris, de sorte qu'une story écrite il y a un mois peut remonter en tête ou tomber au fond sans jamais être réécrite. - Tenir la conversation
À l'approche de la livraison, la story s'élabore avec l'équipe. C'est là qu'on lui adjoint ce dont l'exécution a besoin et que la carte n'aurait pas dû porter: un modèle de données, des règles métier, une maquette d'écran, un diagramme d'état. - Définir les critères d'acceptation
La Confirmation, souvent écrite dans la forme « étant donné, quand, alors ». Ils se définissent en même temps que la carte: ils disent ce que la story veut dire pour de bon et ils sont ce qui la rend testable. - Vérifier INVEST et décomposer si besoin
Une story trop grosse ou non indépendante se coupe en stories plus petites. La décomposition de stories est la technique dédiée à ce découpage; la séance de story mapping désigne les stories qui y passent. - Affiner en continu
Le raffinement du backlog est un travail récurrent: les stories se clarifient, se redécoupent et se repriorisent à mesure que l'équipe apprend.
Ce qui fait échouer une story
La story écrite comme une tâche
« En tant que développeur, je veux refactorer le module de paiement » est un travail technique déguisé, sans partie prenante et sans valeur. Une story nomme un bénéficiaire et un bénéfice.
La story trop grosse pour une itération
Elle viole Small et Estimable et doit être décomposée.
Le « afin de » qui manque
L'Agile Extension nomme ce piège: l'équipe se concentre sur la fonctionnalité et laisse tomber la valeur. La valeur est la raison d'être de la story.
Les critères d'acceptation traités en pensée après coup
La Confirmation est intégrante; sans elle, il n'y a rien contre quoi valider.
La carte prise pour une spécification complète
On oublie la Conversation, et le jeton se met à prétendre à l'exhaustivité qu'il n'a jamais eue.
Le backlog qui enfle
La décomposition multiplie les stories, et sans raffinement le backlog pourrit sous son propre poids.
La vision perdue de vue
À force de regarder chaque story, on cesse de regarder le produit; la feuille de route est ce qui garde le cap au-dessus des cartes.
Considérations IA
Un modèle aide à la mise en forme. On lui donne une transcription d'entretien, une note de fonctionnalité ou un compte rendu d'atelier, et l'on obtient une première carte dans la forme qui, quoi, pourquoi, avec une proposition de critères d'acceptation en « étant donné, quand, alors ». C'est un point de départ que l'on discute et qui évite de partir de zéro. Un modèle rend trois autres services concrets. Il propose un découpage d'une story trop grosse en candidats plus petits, que l'équipe valide ou rejette. Il passe un lot de stories au crible d'INVEST pour signaler mécaniquement le « afin de » absent, la story écrite comme une tâche ou l'énoncé qu'on ne saura pas estimer. Et il aligne les cartes en français, en allemand et en anglais pour une équipe qui travaille dans les trois langues du pays.
Les limites sont dures et elles tiennent à ce qu'une story est. La priorisation est une décision d'affaires: la valeur et la fréquence sont des propriétés de cette organisation et de sa clientèle, un modèle n'y a pas accès et sommé de trancher il produira un ordre plausible et faux. La conversation ne s'automatise pas: l'exigence se transmet entre des personnes, et une carte écrite par la machine qui court-circuite la conversation recrée exactement le piège que la technique existe pour éviter, celui de la carte prise pour une spécification. Les critères d'acceptation qui engagent de l'argent ou de la conformité se vérifient auprès du métier: un modèle invente un seuil, un montant en CHF ou un délai qui a l'air juste et qui ne correspond à aucune règle de la maison. Enfin, transcriptions d'entretien et backlogs portent des données personnelles, et elles ne partent pas dans un modèle public.
Exemples
Un cabinet de physiothérapie de Suisse romande ajoute la réservation de rendez-vous en ligne. Le besoin d'un patient devient une story dont la carte, avec ses critères d'acceptation, est le livrable réel.
Ce que la carte montre et qu'une ligne de spécification cacherait, c'est le « afin de ». « Réserver un créneau en ligne » est une fonctionnalité; « afin de ne pas devoir téléphoner pendant les heures d'ouverture » est la raison qui la rend prioritaire et qui dira, plus tard, si une autre solution ferait aussi bien l'affaire. Sans cette moitié, il reste une tâche, sans partie prenante et sans valeur.
Les deux critères d'acceptation sont la Confirmation, écrite dans la forme « étant donné, quand, alors ». Ils disent ce que « réservé » veut dire pour de bon, ils deviennent les cas de test et ils sont la seule chose sur la carte qui se vérifie objectivement. Le reste appelle la conversation où le détail se réglera, quel délai d'annulation, quel rappel, quelle langue pour le courriel. Mesurée à INVEST, la story tient: indépendante du paiement, qui est une autre story, de valeur pour le patient nommé, assez petite pour une itération et testable par ses deux critères.
Visualisations
La technique produit un artefact, la carte de story. Ce sont des blocs étiquetés positionnés dans l'espace, l'énoncé de valeur au-dessus et la bande des critères d'acceptation en dessous, que le dessin rend mieux qu'une liste. Le modèle des trois C se lit de la même manière, en trois panneaux reliés qui portent le passage du jeton à la conversation puis à la preuve, et il se dessine aussi. INVEST, en revanche, est fait de lignes et de colonnes, une par critère, et ce qui est fait de lignes et de colonnes se rend en tableau.
Coût
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Faible | La story suppose une partie prenante identifiée et un backlog pour l'accueillir, rien de plus. Le travail lourd est l'élicitation en amont, qui fait remonter le besoin; la story, elle, ne demande aucune installation, aucune donnée à rassembler, aucune licence. |
| Exécution | Moyen | Écrire la carte prend quelques minutes, mais son coût réel est la conversation et les critères d'acceptation, qui se rejouent pour chaque story et à chaque itération, ainsi que le raffinement continu du backlog. |
| Documentation | Faible | La carte est délibérément minimale et de court terme, il y a donc peu à consigner. C'est aussi sa limite: le savoir qui doit survivre s'écrit ailleurs. |
Outils
L'outillage minimal est la fiche cartonnée, avec un mur pour tenir le backlog. La contrainte physique de la carte est ici une vertu: ce qui ne tient pas dessus est trop gros, et le geste de réordonner des cartes sur un mur est exactement la priorisation. Le tableau blanc et les notes autocollantes occupent la même place dans une équipe colocalisée.
Le tableur suffit à tenir un petit backlog, une ligne par story, avec sa priorité, son estimation et ses critères. Les outils de gestion de backlog (Jira, Azure DevOps, GitLab, Trello et leurs semblables) prennent le relais dès qu'il faut relier la story à son estimation, à ses critères d'acceptation, à ses tâches et aux exigences qu'elle trace, et dès que l'équipe est dispersée: c'est ce qui fait survivre le backlog à la distance, là où le mur ne suit plus.
Les outils de spécification par l'exemple (Cucumber, SpecFlow et leurs pareils) prolongent la Confirmation: ils exécutent les critères d'acceptation écrits en « étant donné, quand, alors » comme des tests automatisés, ce qui referme la boucle entre la story et sa vérification. Aucun outil n'est requis pour autant. Une carte sur un mur, avec deux critères d'acceptation écrits au dos, est une instance complète de la technique.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.48 User Stories: la définition, la liste des usages, les quatre éléments (titre, énoncé de valeur, conversation, critères d'acceptation) et la limite énoncée, une capture de court terme qui ne vaut ni conservation du savoir à long terme ni base de gouvernance.
- IIBA, Agile Extension to the BABOK Guide, §7.21 User Stories: le traitement agile complet, la vie de la story sur un backlog, le modèle des trois C, la reformulation du « S » d'INVEST en Sized Appropriately, les relations de gestion de la story et les pièges du « afin de » perdu, du backlog qui enfle et de la vision oubliée.
- Mike Cohn, User Stories Applied for Agile Software Development, Addison-Wesley, 2004: le gabarit de Connextra qui, quoi, pourquoi et le cadre du backlog produit; l'autorité de la forme normative de la story.
- Ron Jeffries, Essential XP: Card, Conversation, Confirmation, 2001: le modèle des trois C et le test qui garde les stories petites, « si le besoin ne tient pas sur la carte, la carte est trop grosse ».
- Bill Wake, INVEST in Good Stories, and SMART Tasks, XP123, 2003: l'heuristique INVEST, les six propriétés d'une story utilisable, indépendante, négociable, de valeur, estimable, petite et testable.