Écrire une user story efficace : le guide complet

On a redécouvert l'intérêt des user stories récemment sur un projet. Après avoir livré un premier chantier, un agent IA, le client est revenu vers nous pour la suite : digitaliser une grosse partie de son activité, et plutôt en mode big-bang. Ils auraient pu envoyer un cahier des charges classique (et prendre 3 mois pour le rédiger), mais ils ont eu une bien meilleure idée : aller voir une à une toutes les personnes concernées et leur demander de lister leurs besoins. Le résultat, c'est un document de 90 pages de Stories, qui nous a servi de cahier des charges pour chiffrer le chantier.

La démarche est assez originale, et j'ai trouvé ça cool pour deux raisons

c'est plus précis qu'un CDC : on parle uniquement de ce que le logiciel DOIT faire, parce que c'est de ça que ses utilisateurs ont BESOIN. Ce n'est pas une vision théorique du projet.
ça ouvre naturellement la porte à la discussion : on ne reçoit pas un bloc figé à exécuter, mais une matière à négocier, à découper et à prioriser ensemble.

Sur un aussi gros chantier (on parle de centaines de jours/homme), ce réflexe change tout : en formulant des besoins plutôt que des solutions, le client nous met dans une position où on peut apporter nos idées dès le départ : proposer des choses, en simplifier d'autres, écarter les fausses bonnes pistes. C'est l'inverse du schéma habituel, où le client rédige son cahier des charges dans son coin, puis l'envoie à l'équipe technique qui doit le traduire après coup en specs techniques.

Un peu comme le gamin qui apporte fièrement son dessin à la maîtresse : le travail est déjà fait, on ne peut plus qu'exécuter. Là, au contraire, on construit à deux.

Le principe

Chaque Story raconte en une phrase ce qu'un utilisateur veut faire et pourquoi. La formulation classique tient en trois morceaux :

En tant que [type d'utilisateur], je veux [faire quelque chose], afin de [obtenir un bénéfice].

Par exemple : « En tant que client de la boutique en ligne, je veux enregistrer ma carte bancaire, afin de ne pas devoir la ressaisir à chaque commande. »

Chaque morceau répond à une question importante :

qui : pour qui on développe
quoi : ce qu'il veut pouvoir faire
pourquoi : le bénéfice réel attendu derrière cette demande

Le "pourquoi" est le plus intéressant parce qu'il explique l'intention : en comprenant pourquoi la personne veut quelque chose, vous pouvez parfois trouver une meilleure solution que celle qu'elle avait imaginée.

À quoi ça sert

Trois idées :

l'équipe se concentre sur l'utilisateur : on développe non pas par plaisir d'écrire du code, mais pour régler des problèmes dans le vrai monde.
la Story est une unité de travail : assez petite pour être estimée, planifiée et livrée dans un délai court (typiquement, quelques jours)
c'est une base de discussion : il faut en parler entre client, chef de projet et développeurs. Une bonne story tient sur un post-it, c'est justement pour ne rien figer à l'écrit et forcer la conversation.

Comment écrire des Stories efficaces

Garder le point de vue de l'utilisateur : "Je veux un bouton bleu" n'est pas une story, puisqu'on impose une solution. "Je veux repérer facilement l'action principale de la page" exprime le vrai besoin et laisse la place à la meilleure solution.
Une Story = un besoin : Si vous voyez un "et" qui relie deux fonctionnalités, découpez la story en deux. Les grosses stories, ça s'appelle des "epics", et c'est un autre sujet.
Rendez-la testable avec des critères d'acceptation : ce sont les conditions qui permettent de savoir que le travail est terminé. Dans l'exemple de la CB sur le site de vente, on pourrait mettre "la carte est enregistrée de façon sécurisée, elle apparaît lors de la commande suivante, l'utilisateur peut la supprimer."
La garder petite et livrable. Si une story est trop grosse pour tenir dans un cycle de travail, elle est trop grosse tout court.

Juger une story : I.N.V.E.S.T.

Six qualités pour une bonne story :

I, Indépendante : elle peut être développée et livrée sans dépendre d'une autre story. Si elle a besoin qu'une autre soit finie d'abord, c'est un signe de dépendance à réduire.
N, Négociable : ce n'est pas un contrat figé. Le quoi et le comment restent ouverts à la discussion entre le client et l'équipe, et c'est justement pour ça qu'on la garde courte.
V, a de la Valeur : elle apporte un bénéfice concret à l'utilisateur ou au client. Si personne ne sait à quoi elle sert, elle n'a rien à faire dans la liste.
E, Estimable : l'équipe peut évaluer l'effort qu'elle représente. Si c'est impossible à estimer, c'est souvent qu'elle est trop floue ou trop grosse, et qu'il faut la clarifier ou la découper.
S, Small (petite) : assez petite pour être livrée dans un seul cycle de travail (quelques jours). Trop grosse = c'est une epic à découper.
T, Testable : on peut vérifier objectivement qu'elle est terminée, grâce à ses critères d'acceptation. Si on ne sait pas dire "c'est fini", elle n'est pas testable.

Plusieurs de ces qualités se répondent. Une story trop grosse (S) devient souvent impossible à estimer (E) et difficile à rendre indépendante (I). Donc quand une story coince, commencer par se demander si elle n'est pas simplement trop large règle souvent plusieurs problèmes d'un coup.

Exemple concret

Prenons un cas simple : une application de prise de notes.

Le mauvais exemple

Voici d'abord une story mal écrite, comme on en voit souvent au début :

"En tant qu'utilisateur, je veux une base de données PostgreSQL avec une table notes indexée sur le champ titre, afin de stocker mes notes."

Il y a deux problèmes :

c'est le point de vue d'un développeur. L'utilisateur s'en fout qu'on utilise Postgres ou autre (et qui, à n'en pas douter, ne sait pas ce que c'est). Cette story ne pourra pas être négociable puisque la moitié des parties n'y comprennent rien.
la solution est imposée : choisir Postgres ou pas (c'est un moteur de base de données), c'est un choix technique qui découlera des stories, de la volumétrie, etc. Ça ne se décide pas sur un post-it, et ça se négocie à l'intérieur de l'équipe technique.

Dans cet exemple, l'index dont on parle, c'est une méthode qui permet ensuite de faire des recherches dans la base de données.

La correction

Donc en fait, l'intention serait :

En tant qu'utilisateur de l'application, je veux retrouver rapidement une note à partir de son titre, afin de ne pas perdre de temps à faire défiler toute ma liste.

On a bien le qui, le quoi, le pourquoi, et aucune mention de la façon dont c'est construit. L'équipe reste libre de choisir la meilleure implémentation.

Les critères d'acceptation

La story seule ne suffit pas à savoir quand le travail est terminé. C'est le rôle des critères d'acceptation. Pour cette story, ils pourraient ressembler à ça :

Un champ de recherche est visible en haut de la liste des notes.
Quand je tape du texte, la liste se filtre pour n'afficher que les notes dont le titre contient ce texte.
La recherche ignore les majuscules/minuscules (« Recette » trouve aussi « recette »).
Si aucune note ne correspond, un message clair m'indique qu'il n'y a pas de résultat.
Quand j'efface ma recherche, la liste complète réapparaît.

Remarquez la différence de nature. La story reste courte et parle du besoin ; elle tient sur un post-it. Les critères, eux, sont une liste de conditions vérifiables, formulées de façon à ce qu'on puisse répondre par oui ou par non à chacune (on pourra en faire une checklist quand on codera la fonctionnalité). C'est ce qui rend la story testable : le jour où les cinq critères sont remplis, tout le monde est d'accord pour dire que c'est fini, sans débat.

Un dernier détail utile : les critères d'acceptation ne doivent pas non plus dériver vers la technique. "La recherche s'exécute en moins de 200 ms" est un critère acceptable (c'est un comportement observable). "La recherche utilise un index full-text" n'en est pas un : c'est une décision de conception qui appartient à l'équipe, pas à la définition du besoin.