Comment écrire une user story quand ce n’est pas vous qui construisez

Une user story est la plus petite unité d’un brief de développement. Bien écrite, elle vous livre ce que vous aviez en tête. Mal écrite, elle devient la facture que vous n’attendiez pas. Voici le format, les quatre tests qui distinguent une story constructible d’un piège, et un exemple travaillé.

Une fondatrice avec qui j’ai travaillé l’an dernier a validé une story en quatre secondes environ. Elle disait : « En tant que client, je veux gérer mon compte. » Elle a hoché la tête, glissé la carte dans le sprint, et filé à un appel commercial. Trois semaines plus tard, l’équipe de développement est revenue avec une facture pour la page de compte : édition du profil, réinitialisation du mot de passe, configuration à deux facteurs, historique de facturation, changement de forfait, export des données, suppression du compte. Tout défendable. Tout « gérer mon compte ». Rien de ce qu’elle avait en tête, à savoir un seul écran où l’utilisateur pourrait changer son e-mail.

Cet écart, c’est ce qu’une user story est censée refermer, et c’est pourquoi apprendre comment écrire une user story compte davantage pour celui qui paie le développement que pour les développeurs qui le font. Une user story est une phrase décrivant une chose qu’une personne précise veut faire avec votre logiciel et pourquoi, assez petite pour être construite et vérifiée en quelques jours. Le format classique, popularisé par Mike Cohn et les premières équipes d’Extreme Programming, est : En tant que [type d’utilisateur], je veux [faire quelque chose], afin de [obtenir un bénéfice]. C’est tout le template. Le difficile, ce n’est pas la phrase. C’est en écrire une qui ne se transforme pas en silence en trois semaines de travail que vous n’avez jamais validées.

Ce qu’est une user story, et ce qu’elle n’est pas

Une user story n’est pas une spécification. Cela déroute les fondateurs venus de la finance et du conseil, qui attendent un document figeant chaque détail à l’avance. La formule de Cohn pour une story, c’est « une promesse de conversation ». La carte est un repère. Elle dit nous sommes d’accord que cela vaut la peine d’être construit et discuté, et elle fait confiance au fait que vous et l’équipe réglerez les détails quand le travail arrivera, pas des mois avant.

C’est ce qu’on appelle les « 3 C », que vous verrez cités partout : Carte, Conversation et Confirmation (Card, Conversation, Confirmation). La carte, c’est la phrase unique. La conversation, c’est là où vous et le développeur découvrez ce que l’écran fait vraiment. La confirmation, c’est comment vous savez tous les deux que c’est fini, et on y viendra, parce que c’est la partie que les fondateurs sautent et celle qui coûte cher.

Donc une story est délibérément incomplète. Mais il y a incomplète-exprès et incomplète-parce-que-floue, et la différence est tout l’enjeu. « En tant que client, je veux gérer mon compte » n’est pas une petite promesse de conversation. C’est un pan entier de fonctionnalité déguisé en story unique. L’équipe peut la chiffrer entre un jour et un mois, et quel que soit leur choix, vous serez surpris.

Le template de user story, et les trois parties qui vous appartiennent vraiment

Voici le format à nouveau, rempli correctement :

En tant qu’acheteur pour la première fois, je veux changer l’adresse e-mail de mon compte, afin de continuer à recevoir les mises à jour de commande après avoir changé de travail.

Trois cases. En tant que qui, je veux quoi, afin de pourquoi. On appelle le « qui/quoi/quand/où/pourquoi » les 5 W d’une story, mais vous, en tant que fondateur, n’en possédez que trois : pour qui c’est, ce que la personne cherche à faire, et pourquoi ça compte. Le quand et le où appartiennent à la conversation avec l’équipe.

Les trois cases ne sont pas de la décoration. Chacune est un levier :

Le qui vous empêche de construire pour un « utilisateur » générique qui n’existe pas. Un acheteur pour la première fois et un utilisateur avancé qui revient sans cesse veulent des choses différentes du même écran. Nommez la personne réelle et la moitié de l’ambiguïté disparaît.

Le quoi est une seule action, pas une capacité. « Changer l’e-mail » est une action. « Gérer les paramètres du compte » est une capacité, et une capacité est un seau qui contient une douzaine de stories. Si votre quoi contient le mot « gérer », « traiter », « prendre en charge » ou « et », arrêtez. Vous avez plus d’une story.

Le afin de est la partie que tout le monde laisse tomber, et la plus utile. Il dit à l’équipe pourquoi vous voulez la chose, ce qui lui permet de proposer un moyen moins cher d’atteindre le même résultat. La moitié du temps, la version du développeur du afin de est meilleure que la fonctionnalité que vous avez demandée. Vous ne le découvrez que si vous l’avez écrit.

Les quatre tests qui distinguent une story constructible d’un piège

Les équipes agiles utilisent une checklist appelée INVEST pour cela. Elle est bonne, et elle a été écrite pour ceux qui exécutent. Voici la traduction pour fondateurs : les quatre questions que je pose réellement avant qu’une story n’entre dans un sprint que je paie.

Peut-elle être construite et me la montrer seule ? Une bonne story est une tranche qui traverse le produit entier, pas une couche de celui-ci. « Construire la base de données des comptes » est une couche. Vous ne pouvez pas la voir, pas la tester, pas dire si elle est juste. « Changer mon e-mail » traverse la base, l’écran et l’e-mail de confirmation d’un coup, et se termine par quelque chose que vous pouvez regarder. Si une story n’a de sens que dans un lot, ce n’est pas encore une story.

Est-elle assez petite pour être finie en quelques jours ? Non pas parce que les développeurs ne peuvent pas faire de grandes choses, mais parce que les grandes stories cachent des surprises, et les surprises sur un budget fixe sortent de votre poche ou de votre délai. Si vous ne pouvez pas imaginer la chose faite en une semaine, c’est un rocher. Divisez-la. « Changer mon e-mail » et « vérifier le nouvel e-mail avant qu’il ne prenne effet » sont deux stories, et les chiffrer séparément vous protège.

Pourrais-je la refuser à la livraison ? Voilà celle à laquelle les fondateurs ne pensent jamais avant qu’il ne soit trop tard. Une story que vous ne pouvez pas recaler est une story que vous paierez deux fois. « Améliorer l’expérience de paiement » ne peut jamais être fausse, ce qui veut dire que vous ne pouvez jamais la renvoyer. « Afficher le total, frais de port compris, avant le bouton payer » le fait ou ne le fait pas. Écrivez des stories que vous pourriez refuser, et vous gardez du pouvoir de négociation jusqu’à la livraison.

Parle-t-elle de l’utilisateur, pas de la plomberie ? « Ajouter un cache Redis » est une tâche technique, et les tâches techniques relèvent de l’équipe, pas de vous. Vos stories décrivent ce que quelqu’un peut faire avec le produit. Si vous vous surprenez à écrire sur des bases de données, des files ou des caches, vous êtes passé du côté développeur de la table. Rendez-le et restez du vôtre.

Critères d’acceptation : comment une story cesse d’être un souhait

C’est ici que la validation en quatre secondes tourne mal et ici que vous en avez pour votre argent. La story est la promesse. Les critères d’acceptation sont la confirmation, la checklist qui dit exactement ce que « terminé » signifie, écrite avant que le travail ne commence. Ils font la différence entre une story dont vous espérez qu’elle sortira bien et une que vous pouvez accepter ou refuser objectivement.

Pour la story de l’e-mail :

• L’utilisateur peut ouvrir les paramètres du compte et voir son e-mail actuel.
• Le changer envoie un lien de vérification à la nouvelle adresse.
• L’e-mail ne change vraiment qu’une fois le lien cliqué.
• Si la nouvelle adresse est déjà utilisée par un autre compte, l’utilisateur voit une erreur claire.
• Les e-mails de mise à jour de commande partent vers la nouvelle adresse seulement après la vérification.

Remarquez ce que ces cinq lignes viennent de faire. Elles ont transformé un souhait d’une phrase en quelque chose que le développeur peut chiffrer avec précision et que vous pouvez vérifier ligne par ligne à la livraison. Elles ont aussi fait surgir une décision (que se passe-t-il avec un e-mail en double ?) qui serait sinon devenue une question en plein sprint, ou pire, une hypothèse silencieuse que vous découvririez en production. Les critères d’acceptation sont peu chers à écrire et chers à sauter. Nous approfondissons cela dans notre texte sur comment écrire des critères d’acceptation qu’un fondateur non technique peut vraiment faire respecter.

Un exemple travaillé : d’une demande floue à une story livrable

Partez de ce que les fondateurs disent réellement lors d’un kickoff : « Je veux que les utilisateurs puissent inviter leurs coéquipiers. »

C’est une capacité, pas une story. C’est le piège du « gérer mon compte » sous un autre costume. Faites-la passer par les tests et elle se divise en stories, chacune que vous pouvez voir, dimensionner et refuser :

En tant que propriétaire du compte, je veux envoyer une invitation par e-mail à un coéquipier, afin qu’il rejoigne mon workspace sans que je partage mon mot de passe.

En tant que coéquipier invité, je veux accepter une invitation et définir mon propre mot de passe, afin d’avoir mon propre accès plutôt qu’un accès partagé.

En tant que propriétaire du compte, je veux voir quelles invitations sont encore en attente, afin de relancer ceux qui n’ont pas rejoint.

Trois stories là où il y avait une ligne. Chacune fait quelques jours de travail, chacune se termine par quelque chose que vous pouvez regarder, et chacune a ses propres critères d’acceptation. Quand l’équipe les chiffre, vous pouvez décider que « voir les invitations en attente » est un bonus et la couper pour tenir une échéance. Vous n’auriez pas pu prendre cette décision sur « laisser les utilisateurs inviter des coéquipiers », parce que vous ne voyiez pas les coutures. Les bonnes stories vous donnent des coutures où couper. C’est à cela qu’elles servent, pour l’essentiel.

Des stories comme celles-ci ne flottent pas dans le vide. Elles reposent sur votre product backlog, ordonné selon ce qui compte, et remontent vers la vision d’ensemble que vous avez posée dans votre document d’exigences produit. La story est l’atome. Le backlog est la molécule. Le document d’exigences est le composé.

Écrivez-en moins, écrivez-les plus serrées

L’instinct, quand vous découvrez le format, est d’écrire quarante stories en un week-end et de livrer une pile. Ne le faites pas. Une pile de stories floues est pire que rien, parce qu’elle donne à tout le monde la fausse confiance que la réflexion est faite. Elle ne l’est pas. Les stories floues sont ce dont le scope creep est vraiment fait : l’expansion silencieuse de « gérer mon compte » en sept écrans, découverte une facture à la fois.

Écrivez les cinq ou six stories de la prochaine tranche de travail. Faites en sorte que chacune passe les quatre tests. Donnez à chacune des critères d’acceptation que vous seriez à l’aise de faire respecter. Ensuite, parlez-en avec celui qui construit, parce que la carte a toujours été une promesse d’avoir cette conversation. Faites cela et la story joue son vrai rôle, qui n’est ni de la documentation ni du process. C’est de garder la chose qui se construit et la chose que vous aviez en tête dans la même pièce.

Questions fréquentes

Quels sont les 3 C d’une user story ?
Carte, Conversation et Confirmation (Card, Conversation, Confirmation). La Carte est la story d’une ligne. La Conversation est la discussion entre vous et l’équipe sur ce qu’elle signifie vraiment. La Confirmation, ce sont les critères d’acceptation qui définissent « terminé ». Le format vient de Ron Jeffries, l’un des auteurs de l’Extreme Programming, et rappelle que la phrase est un point de départ, pas l’accord entier.

Qu’est-ce qu’un exemple de user story ?
« En tant qu’acheteur pour la première fois, je veux changer l’adresse e-mail de mon compte, afin de continuer à recevoir les mises à jour de commande après avoir changé de travail. » Elle nomme un utilisateur précis, une seule action concrète et la raison derrière. Comparez avec « En tant qu’utilisateur, je veux gérer mon compte », qui ne nomme personne, décrit un pan entier de fonctionnalité et ne peut être ni chiffré ni refusé.

Qu’est-ce qu’un template de user story ?
Le template standard est : En tant que [type d’utilisateur], je veux [faire quelque chose], afin de [obtenir un bénéfice]. Remplissez les trois cases. Si la case du milieu contient « et », « gérer » ou « prendre en charge », vous avez presque à coup sûr plus d’une story et devriez la diviser.

Quels sont les 5 W dans les user stories ?
Qui, quoi, quand, où et pourquoi (who, what, when, where, why). En pratique, un fondateur en possède trois : pour qui est la story, ce que la personne veut faire et pourquoi ça compte. Le quand et le où (quel écran, quel état, quel cas limite) se règlent dans la conversation avec celui qui construit, et se figent dans les critères d’acceptation.

Qu’est-ce que la règle 3-5-3 en agile ?
Elle renvoie à la structure de Scrum : 3 rôles, 5 événements et 3 artefacts. Elle porte sur la façon dont une équipe Scrum s’organise, pas sur la façon d’écrire une story, c’est donc une question différente de celle-ci. Si vous commandez un développement plutôt que de piloter l’équipe vous-même, le format de story ci-dessus compte bien plus que le décompte des cérémonies.