4 min lecture • Guide 270 of 877
Écrire des User Stories Efficaces
Les user stories ne sont pas des documents d'exigences—ce sont des placeholders pour des conversations. Une bonne user story capture qui a besoin de quoi et pourquoi, est assez petite pour être complétée dans un sprint, et invite à la discussion sur les détails. Ce guide couvre l'écriture de stories qui aident vraiment les équipes à construire la bonne chose.
Éléments de Story
| Élément | Objectif | Exemple |
|---|---|---|
| Rôle Utilisateur | Qui bénéficie | "En tant que client..." |
| Objectif | Ce qu'ils veulent | "...je veux sauvegarder mon panier..." |
| Bénéfice | Pourquoi ça compte | "...pour pouvoir revenir plus tard" |
| Critères | Définition de terminé | "Panier persiste 30 jours" |
Format de Story
Le Template Classique
TEMPLATE USER STORY
═══════════════════
FORMAT:
─────────────────────────────────────
En tant que [type d'utilisateur]
Je veux [objectif/désir]
Afin de [bénéfice/valeur]
Critères d'Acceptation:
├── Étant donné [contexte], quand [action], alors [résultat]
├── Étant donné [contexte], quand [action], alors [résultat]
└── ...
EXEMPLE:
─────────────────────────────────────
En tant qu'acheteur fréquent
Je veux sauvegarder des articles dans ma liste de souhaits
Afin de pouvoir les retrouver facilement plus tard pour achat
Critères d'Acceptation:
├── Étant donné que je suis sur une page produit
│ Quand je clique "Ajouter à la Liste de Souhaits"
│ Alors l'article apparaît dans ma liste de souhaits
│
├── Étant donné que je visualise ma liste de souhaits
│ Quand je clique "Ajouter au Panier" sur un article
│ Alors l'article passe dans mon panier
│
├── Étant donné que j'ai des articles dans ma liste
│ Quand je reviens la semaine suivante
│ Alors mes articles de liste sont toujours là
│
└── Étant donné qu'un article devient indisponible
Quand je visualise ma liste de souhaits
Alors je vois "Rupture de stock" sur cet article
COMPOSANTS EXPLIQUÉS:
─────────────────────────────────────
TYPE D'UTILISATEUR:
├── Pour qui est-ce?
├── Être spécifique: "Nouvel utilisateur" vs "Admin" vs "Abonné Premium"
├── Persona si vous en avez
└── Aide à prioriser et designer
OBJECTIF:
├── Que veulent-ils faire?
├── Capacité fonctionnelle
├── Pas COMMENT, juste QUOI
└── Langage utilisateur, pas technique
BÉNÉFICE:
├── Pourquoi ça compte?
├── La vraie motivation
├── Aide à comprendre les compromis
└── Parfois révèle de meilleures solutions
Critères INVEST
Contrôle Qualité Story
CRITÈRES INVEST
═══════════════
I - INDÉPENDANTE
─────────────────────────────────────
Les stories doivent pouvoir être terminées seules.
Pas: "L'utilisateur peut payer (nécessite story panier)"
Oui: Chaque story livrable indépendamment
Si des dépendances existent, les noter mais minimiser.
N - NÉGOCIABLE
─────────────────────────────────────
Les stories sont des démarreurs de conversation, pas des contrats.
Les détails émergent par la discussion.
Ne pas sur-spécifier à l'avance.
Place pour l'input de l'équipe sur l'implémentation.
V - VALORISABLE (Valuable)
─────────────────────────────────────
Chaque story livre de la valeur à quelqu'un.
Pas: "Installer la base de données" (pas de valeur utilisateur directe)
Oui: "L'utilisateur peut sauvegarder ses préférences" (valeur)
Le travail technique peut être des stories, mais lier à la valeur.
E - ESTIMABLE
─────────────────────────────────────
L'équipe peut estimer l'effort.
Si non estimable:
├── Trop vague → Besoin plus de détails
├── Trop grande → Besoin de diviser
S - SMALL (Petite)
─────────────────────────────────────
Terminable en quelques jours.
1-5 story points idéalement.
Si plus grande, diviser.
T - TESTABLE
─────────────────────────────────────
Peut vérifier quand c'est terminé.
Critères d'acceptation clairs.
Pas de "ça devrait se sentir mieux".