Guide agile · Pratiques agiles
User stories : comment les rédiger, avec modèles et exemples
Une user story est une description courte et en langage simple d'un besoin d'un utilisateur, rédigée de son point de vue. Elle indique qui le souhaite, ce qu'il souhaite et pourquoi, et sert de point de départ à une conversation sur les détails plutôt que de spécification complète.
À retenir
- Une user story indique qui a besoin de quelque chose, de quoi il a besoin et pourquoi.
- Les critères d'acceptation rendent chaque story testable ; la Definition of Done s'applique à toutes les stories.
- Utilisez INVEST pour vérifier la qualité et découpez les stories qui ne tiendront pas dans un sprint.
- Les stories sont un point de départ pour la conversation, pas une spécification complète.
Le modèle de user story
Le format le plus courant est : En tant que [type d'utilisateur], je veux [un objectif] afin de [un bénéfice].
- Qui : un utilisateur ou un rôle précis, pas « le système ».
- Quoi : l'objectif ou la capacité dont il a besoin, et non la solution technique.
- Pourquoi : le bénéfice, ce qui aide l'équipe à trouver la manière la plus simple de le livrer.
De nombreuses équipes décrivent une story selon les trois C : la carte (la courte story écrite), la conversation (la discussion qui précise les détails) et la confirmation (les critères d'acceptation qui montrent qu'elle est terminée).
Critères d'acceptation
Les critères d'acceptation sont les conditions qu'une story doit remplir pour être acceptée. Ils rendent la story testable et réduisent les malentendus. Deux styles courants :
- Check-list : « La réservation indique l'heure et le lieu du cours » ; « L'adhérent reçoit un e-mail de confirmation ».
- Étant donné-Quand-Alors : « Étant donné qu'un cours a des places libres, quand un adhérent appuie sur Réserver, alors une place est réservée et le nombre de places libres diminue d'une unité. »
La check-list INVEST
| Lettre | Signification | Question à se poser |
|---|---|---|
| I | Indépendante | Peut-elle être livrée sans attendre une autre story ? |
| N | Négociable | Les détails sont-ils ouverts à la discussion plutôt que figés ? |
| V | Valorisable | Apporte-t-elle de la valeur à un utilisateur ou à l'entreprise ? |
| E | Estimable | L'équipe la comprend-elle suffisamment pour l'estimer ? |
| S | Petite | Peut-elle être terminée en un seul sprint ? |
| T | Testable | Les critères d'acceptation sont-ils clairs ? |
Comment rédiger une user story, étape par étape
- Identifiez l'utilisateur et son objectif, idéalement à partir de recherches ou de retours réels.
- Rédigez la story à l'aide du modèle, en une ou deux phrases.
- Ajoutez trois à six critères d'acceptation.
- Discutez-en avec l'équipe pendant l'activité appelée affinage du backlog et ajustez-la.
- Vérifiez-la avec INVEST ; découpez-la si elle est trop grande.
- Estimez-la, par exemple avec des story points.
- Ordonnez-la dans le backlog produit selon la valeur, le risque et les dépendances.
Exemples : faibles et améliorées
| Story faible | Story améliorée |
|---|---|
| En tant qu'utilisateur, je veux une table de base de données pour les réservations. | En tant qu'adhérent, je veux réserver un cours afin que ma place soit garantie. |
| En tant que système, je veux envoyer des e-mails. | En tant qu'adhérent, je veux un e-mail de confirmation de réservation afin de garder une trace de mon cours. |
| En tant qu'utilisateur, je veux que le site soit rapide. | En tant qu'utilisateur mobile, je veux que le planning se charge en moins de deux secondes afin de réserver en déplacement. |
| En tant qu'administrateur, je veux un module de reporting avec 15 rapports. | En tant que gérant de salle de sport, je veux voir la fréquentation hebdomadaire par cours afin d'ajuster le planning. |
Exemple complet : En tant qu'adhérent, je veux m'inscrire sur une liste d'attente lorsqu'un cours est complet afin d'obtenir une place si quelqu'un annule. Critères d'acceptation : le bouton Rejoindre la liste d'attente n'apparaît que lorsqu'un cours est complet ; l'adhérent voit sa position ; lorsqu'une place se libère, elle est proposée par e-mail à la première personne, qui dispose de deux heures pour l'accepter.
Erreurs courantes
- Rédiger des tâches techniques déguisées en stories.
- Des stories si grandes qu'elles s'étendent sur plusieurs sprints ; traitez-les comme des epics et découpez-les.
- Absence de clause « afin de », ce qui masque le besoin réel.
- Traiter la story comme un contrat au lieu d'engager une conversation.
- Critères d'acceptation absents ou vagues, qui entraînent des reprises.
- Rédiger chaque story selon le modèle même lorsqu'une phrase simple serait plus claire.
Modèles gratuits sur ce sujet
Questions fréquentes
Qu'est-ce qu'une user story en agile ?
Une courte description d'un besoin utilisateur, rédigée du point de vue de l'utilisateur, que l'équipe transforme en fonctionnalité opérationnelle.
Quel est le format d'une user story ?
En tant que [type d'utilisateur], je veux [objectif] afin de [bénéfice].
Qui rédige les user stories ?
Tout le monde peut en rédiger, mais le Product Owner est généralement chargé de veiller à ce qu'elles soient claires et ordonnées dans le backlog.
Les user stories font-elles partie de Scrum ?
Non. Le Guide Scrum parle d'éléments du Product Backlog ; les user stories sont une manière répandue de les rédiger.
Que sont les critères d'acceptation des user stories ?
Conditions précises et testables qu'une story doit remplir pour être acceptée, souvent rédigées sous forme de check-list ou au format Étant donné-Quand-Alors.
Quelle taille doit avoir une user story ?
Suffisamment petite pour être terminée en un sprint, et idéalement en quelques jours.
Que signifie INVEST pour les user stories ?
Indépendante, Négociable, Valorisable, Estimable, Petite (Small) et Testable.
Quelle est la différence entre une user story et une exigence ?
Une exigence traditionnelle précise en détail ce que le système doit faire ; une user story décrit un besoin et invite à la conversation pour s'accorder sur les détails. Voir exigences du projet.
Quelle est la différence entre une user story et un epic ?
Un epic est un vaste ensemble de travail composé de nombreuses stories ; une story tient dans un seul sprint.
Comment estimer les user stories ?
La plupart des équipes utilisent une estimation relative, comme les story points ou des tailles de T-shirt, convenues ensemble par l'équipe.
Les user stories peuvent-elles être utilisées en dehors du logiciel ?
Oui. Le marketing et d'autres équipes rédigent des stories comme « En tant que client potentiel, je veux un comparatif des tarifs afin de choisir une formule » ; voir Marketing agile.