Écrire de Meilleures User Stories
Rédigez des user stories que les équipes peuvent livrer. Critères d'acceptation clairs, bon niveau de détail et résultats testables.
4 min de lecture
Les bonnes user stories communiquent l'intention clairement. GitScrum fournit des templates et des champs qui aident les équipes à écrire des stories avec le bon niveau de détail.
Bases des User Stories
Format de Story
STRUCTURE USER STORY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FORMAT CLASSIQUE: │
│ │
│ En tant que [type d'utilisateur] │
│ Je veux [un objectif] │
│ Afin de [une raison/bénéfice] │
│ │
│ EXEMPLE: │
│ │
│ En tant que chef de projet │
│ Je veux exporter les rapports en PDF │
│ Afin de partager l'avancement avec les parties prenantes │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ POURQUOI CE FORMAT FONCTIONNE: │
│ │
│ QUI: Identifie le type d'utilisateur │
│ → Aide à comprendre le contexte │
│ │
│ QUOI: Énonce la fonctionnalité désirée │
│ → Objectif clair │
│ │
│ POURQUOI: Explique le besoin sous-jacent │
│ → Permet des solutions alternatives │
│ → Empêche "juste construire ce que j'ai dit" │
│ │
│ FORMAT ALTERNATIF (si plus simple): │
│ │
│ "Permettre aux chefs de projet d'exporter des rapports PDF"│
│ │
│ Le format est un outil, pas une règle │
│ Clarté > suivre le format rigidement │
└─────────────────────────────────────────────────────────────┘
Critères INVEST
CHECKLIST INVEST:
┌─────────────────────────────────────────────────────────────┐
│ │
│ I - INDÉPENDANTE │
│ Peut être développée sans dépendre d'autres stories │
│ ❌ "Après que la story A soit faite, on peut faire B" │
│ ✅ Story B est autonome │
│ │
│ N - NÉGOCIABLE │
│ Les détails peuvent être discutés et ajustés │
│ ❌ "Construire exactement cette UI avec ces 27 champs" │
│ ✅ "L'utilisateur doit configurer les notifications" │
│ │
│ V - VALUABLE (Valorisable) │
│ Livre de la valeur à l'utilisateur ou au business │
│ ❌ "Refactoriser la couche base de données" │
│ ✅ "Les utilisateurs expérimentent des chargements plus rapides"│
│ │
│ E - ESTIMABLE │
│ L'équipe peut estimer l'effort │
│ ❌ Trop vague pour dimensionner │
│ ✅ Assez clair pour discuter de la complexité │
│ │
│ S - SMALL (Petite) │
│ Tient dans un sprint │
│ ❌ "Construire tout le système de checkout" │
│ ✅ "Ajouter l'option de paiement par carte de crédit" │
│ │
│ T - TESTABLE │
│ On peut vérifier quand c'est terminé │
│ ❌ "Rendre l'app plus rapide" │
│ ✅ "La page charge en moins de 2 secondes" │
│ │
│ UTILISER: Revoir les stories contre INVEST avant planif │
└─────────────────────────────────────────────────────────────┘
Critères d'Acceptation
Écrire les Critères
EXEMPLES CRITÈRES D'ACCEPTATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ STORY: En tant qu'utilisateur, je peux exporter mes données│
│ en CSV │
│ │
│ CRITÈRES D'ACCEPTATION: │
│ │
│ ✅ BONS CRITÈRES: │
│ │
│ ÉTANT DONNÉ que je suis sur la page de grille de données │
│ QUAND je clique sur le bouton "Exporter" │
│ ALORS un fichier CSV se télécharge sur mon ordinateur │
│ │
│ ÉTANT DONNÉ que j'ai sélectionné des colonnes spécifiques│
│ QUAND j'exporte │
│ ALORS seules les colonnes sélectionnées apparaissent │
│ │
│ ÉTANT DONNÉ que le dataset a 50 000 lignes │
│ QUAND j'exporte │
│ ALORS l'export se termine en moins de 30 secondes │
│ ET je vois un indicateur de progression │
└─────────────────────────────────────────────────────────────┘