Comment rédiger des user stories (avec exemples et critères d'acceptation)
Une user story est une description courte d'une fonctionnalité du point de vue de l'utilisateur : « En tant que [type d'utilisateur], je veux [objectif] afin de [raison]. » Sous celle-ci, vous rédigez les critères d'acceptation, quelques conditions précises qui doivent être vraies pour que la story soit considérée comme terminée. Gardez chaque story assez petite pour la construire et la tester en une fois, et rédigez les critères de façon que n'importe qui puisse les vérifier.
Les user stories se sont imposées dans les équipes logicielles agiles, mais elles sont tout aussi utiles lorsque vous construisez seul avec un générateur d'applications par IA. Une bonne story est un bon prompt.
Le format
Une user story comporte trois éléments :
En tant que [qui], je veux [quoi] afin de [pourquoi].
- Qui désigne un type précis d'utilisateur : un visiteur qui découvre le site, un adhérent payant, un réceptionniste de clinique, un administrateur. Pas « l'utilisateur ».
- Quoi est ce que la personne veut faire, dans ses propres mots. Pas le fonctionnement de l'écran.
- Pourquoi est le résultat qui lui importe. C'est la partie que l'on oublie souvent, et celle qui empêche de construire la mauvaise chose.
Exemple :
En tant que membre de salle de sport, je veux annuler une réservation de cours depuis mon téléphone afin que quelqu'un sur la liste d'attente puisse prendre ma place et que je ne sois pas facturé de frais d'absence.
Le « pourquoi » vous apprend deux choses que le « quoi » ne disait pas : cela doit fonctionner sur téléphone, et la liste d'attente et les règles de frais entrent en jeu.
Critères d'acceptation
La story dit ce qui est souhaité. Les critères d'acceptation disent quand c'est terminé. Ils doivent être assez précis pour que deux personnes s'accordent sur la réussite ou non de chacun.
Une façon courante de les écrire est le format Étant donné / Quand / Alors :
- Étant donné une situation de départ
- Quand l'utilisateur fait quelque chose
- Alors voici le résultat
Pour la story de réservation de salle de sport :
- Étant donné que j'ai une réservation dans plus de 12 heures, quand je touche Annuler puis je confirme, alors la réservation est supprimée et je vois « Réservation annulée ».
- Étant donné que j'annule une réservation et que le cours a une liste d'attente, quand l'annulation est enregistrée, alors la première personne de la liste d'attente obtient la place et un e-mail.
- Étant donné une réservation dans moins de 12 heures, quand je touche Annuler, alors je vois que des frais d'annulation tardive s'appliquent avant de confirmer.
- Étant donné que je suis sur un écran de largeur téléphone, alors le bouton Annuler est visible sans défilement horizontal.
Une simple liste de contrôle fonctionne aussi, à condition que chaque point soit testable. « Annuler est facile » n'est pas testable. « Annuler prend au maximum deux touches depuis la liste des réservations » l'est.
Étape par étape : rédiger une bonne story
Étape 1 : partir d'un vrai utilisateur et d'un vrai problème
Choisissez un type d'utilisateur et une difficulté qu'il rencontre aujourd'hui. Si vous avez mené des entretiens clients, utilisez leurs mots. « J'oublie toujours d'annuler et je me fais débiter » est un meilleur point de départ que « ajouter une fonctionnalité d'annulation ».
Étape 2 : rédiger la story en une ligne
Complétez le modèle. Si vous ne parvenez pas à écrire un « afin de » convaincant, demandez-vous si la fonctionnalité est vraiment nécessaire.
Étape 3 : ajouter trois à six critères d'acceptation
Couvrez d'abord le cas de succès principal, puis les variantes importantes : un autre rôle, un état vide, une limite, une erreur. Si vous en écrivez plus de six, la story est probablement trop grosse.
Étape 4 : noter ce qui est hors périmètre
Une ligne évite beaucoup d'allers-retours : « Hors périmètre : remboursements pour les cours payants ; annulations faites par les administrateurs au nom des membres. » Cela empêche la story de grossir pendant la construction.
Étape 5 : vérifier avec INVEST
INVEST est une liste de contrôle courante pour les bonnes stories. Une story doit être :
| Lettre | Signifie | Test rapide |
|---|---|---|
| I | Indépendante | Peut être construite sans attendre une autre story |
| N | Négociable | Décrit le besoin, pas une conception figée |
| V | Valeur | Un utilisateur remarquerait si elle était livrée |
| E | Estimable | Vous pouvez deviner à peu près sa taille |
| S | Petite | Construite et testée en une séance |
| T | Testable | Chaque critère d'acceptation peut être vérifié |
Inutile de noter chaque story. C'est surtout utile lorsqu'une story vous semble bancale et que vous voulez comprendre pourquoi.
Exemples bons et mauvais
| Story faible | Problème | Story meilleure |
|---|---|---|
| En tant qu'utilisateur, je veux un tableau de bord. | Pas d'utilisateur précis, pas de raison, non testable | En tant que propriétaire de boutique, je veux voir les commandes et le chiffre d'affaires du jour sur un seul écran afin de savoir d'un coup d'œil si la journée se passe bien. |
| En tant qu'administrateur, je veux que la base de données ait une colonne statut. | Décrit l'implémentation, pas un besoin | En tant qu'administrateur, je veux marquer les commandes comme expédiées afin que les clients arrêtent de m'écrire pour demander où elles en sont. |
| En tant que client, je veux gérer mon compte. | Trop large : couvre de nombreuses fonctionnalités | En tant que client, je veux changer mon adresse e-mail afin que les reçus arrivent dans ma nouvelle boîte. |
| En tant que visiteur, je veux que le site soit rapide. | Ce n'est pas une story ; c'est une qualité que tout le monde attend | Écrivez-le comme critère sur chaque story, ou comme objectif de performance distinct. |
Comment découper une story trop grosse
Les grosses stories sont là où les projets s'enlisent. Les façons courantes de les découper :
- Par rôle d'utilisateur. Les membres annulent leurs propres réservations ; le personnel annule celles de n'importe qui.
- Par étape du parcours. Parcourir les cours ; réserver un cours ; recevoir un rappel.
- Cas simple d'abord. Annuler un cours gratuit maintenant ; gérer les frais et les remboursements dans une story ultérieure.
- Par variation de données. Prendre en charge un seul site d'abord, plusieurs plus tard.
- Le cas nominal, puis les erreurs. Faire fonctionner la version nominale, puis ajouter la gestion des cours complets, des forfaits expirés, etc.
Chaque morceau doit rester quelque chose qu'un utilisateur pourrait utiliser et remarquer.
Utiliser les user stories comme prompts
Une user story avec ses critères d'acceptation se rapproche beaucoup d'un bon prompt pour un générateur d'applications par IA. Elle donne à l'IA le qui, le quoi, le pourquoi et une définition du terminé. Envoyez une story par message :
En tant que membre de salle de sport, je veux annuler une réservation de cours depuis mon téléphone afin que quelqu'un sur la liste d'attente puisse prendre ma place. Critères d'acceptation :
- L'annulation est disponible sur chaque réservation dans Mes réservations, avec une étape de confirmation.
- Une annulation plus de 12 heures avant le cours supprime simplement la réservation.
- Moins de 12 heures avant, afficher « Des frais d'annulation tardive de 5 $ s'appliquent » avant confirmation, et enregistrer les frais sur la réservation.
- Si le cours a une liste d'attente, la première personne obtient la place et un e-mail.
- Fonctionne sur un écran de largeur téléphone. Hors périmètre : remboursements, annulations faites par le personnel pour les membres. Construis ceci, puis vérifie chaque critère dans l'aperçu et dis-moi lesquels passent.
Vous pouvez aussi demander à l'IA de rédiger des stories à partir d'une idée brute, puis les modifier vous-même :
Voici mon idée d'application : [deux ou trois phrases]. Rédige les user stories d'une première version, regroupées par type d'utilisateur, chacune avec 3 à 5 critères Étant donné / Quand / Alors. Indique lesquelles sont indispensables au lancement et lesquelles peuvent attendre.
Relisez et modifiez toujours le résultat. L'IA ne connaît pas vos utilisateurs ; vous, si.
Les critères d'acceptation servent aussi de plan de test. Une fois la story construite, parcourez vous-même chaque critère. Notre guide sur tester votre application avant le lancement s'appuie sur cette démarche.
Où les user stories s'insèrent parmi les autres documents
- Un PRD décrit l'ensemble du produit : le problème, les utilisateurs, le périmètre. Les user stories en sont les pièces détaillées. Voir comment rédiger un PRD avec l'IA.
- Un rapport de bug décrit ce qui est cassé par rapport à une story déjà construite. Voir comment rédiger un bon rapport de bug.
- Un MVP est l'ensemble minimal de stories qui apporte la valeur essentielle. Voir qu'est-ce qu'un MVP.
Erreurs courantes
- « En tant qu'utilisateur… » Trop vague. Nommez le type d'utilisateur réel.
- Oublier le « afin de ». Sans la raison, impossible de faire des arbitrages sensés.
- Écrire la solution au lieu du besoin. « Je veux une liste déroulante » fige une conception avant que quiconque ait réfléchi.
- Des critères non testables. « Facile », « rapide » et « intuitif » sont des souhaits, pas des critères.
- Des stories qui sont en réalité des épopées. « Gérer mon compte » représente dix stories.
- Rédiger toutes les stories à l'avance. Rédigez les prochaines en détail ; gardez le reste en une ligne jusqu'à ce que vous y arriviez.
Les stories dans Mythex
Dans Mythex, le mode Plan est un bon endroit pour transformer une idée en stories : l'agent discute de l'approche avant de modifier quoi que ce soit. Quand une story est prête, passez en mode Build et collez-la, une story par message. Après chacune, /test peut parcourir l'aperçu et vérifier le parcours, et vous pouvez annuler toute réponse avec Revenir à ce point si elle a mal tourné. Voir les prompts efficaces dans la documentation, et notre guide sur l'écriture de prompts pour les générateurs d'applications par IA.
Liste de contrôle des user stories
- Nomme un type d'utilisateur précis
- Décrit un besoin, pas une conception
- Contient une vraie raison dans le « afin de »
- Compte trois à six critères d'acceptation testables
- Couvre au moins un cas limite ou une erreur
- Indique ce qui est hors périmètre
- Assez petite pour être construite et testée en une fois
- Critères vérifiés un par un après la construction
Questions
Quel est le format d'une user story ?
Le modèle courant est : En tant que [type d'utilisateur], je veux [objectif] afin de [raison]. Il est suivi de critères d'acceptation, une courte liste de conditions qui doivent être vraies pour que la story soit considérée comme terminée.
Qu'est-ce que les critères d'acceptation ?
Les critères d'acceptation sont des conditions précises et testables qui définissent quand une user story est terminée. Ils sont souvent écrits au format Étant donné / Quand / Alors : étant donné une situation de départ, quand l'utilisateur fait quelque chose, alors un résultat précis se produit.
Quelle doit être la taille d'une user story ?
Assez petite pour être construite et testée en une seule fois, et tout de même utile à elle seule. Si une story compte plus de cinq ou six critères d'acceptation ou couvre plusieurs écrans, découpez-la par rôle d'utilisateur, par étape du parcours, ou par cas simple d'abord, avec les cas limites pour plus tard.
Les user stories sont-elles utiles quand on construit avec l'IA ?
Oui. Une user story assortie de critères d'acceptation se rapproche d'un prompt idéal : elle indique pour qui est la fonctionnalité, ce dont cette personne a besoin et exactement comment vérifier que cela fonctionne. Envoyer une story par message garde aussi les modifications de l'IA petites et faciles à tester.