User Stories : Rédaction et Critères d'Acceptation

1. Qu'est-ce qu'une User Story ?

Une User Story (ou "récit utilisateur") est une description simple et courte d'une fonctionnalité, racontée du point de vue de la personne qui désire cette nouvelle capacité, généralement un utilisateur ou un client du système.

Plutôt qu'un long document de spécifications techniques, une User Story est souvent considérée comme une "promesse de conversation". Elle n'est pas censée contenir tous les détails, mais juste assez d'informations pour que l'équipe puisse en discuter, estimer l'effort nécessaire et la planifier.

La structure d'une User Story

La structure la plus courante et la plus efficace est la suivante :

En tant que <type d'utilisateur>, je souhaite <réaliser une action> afin de <bénéfice / objectif>.

Pour découvrir cette structure et son utilité, je vous propose de regarder un court extrait vidéo.

Ce format est puissant car il force à réfléchir à trois questions essentielles :

• Qui ? (En tant que...) : On identifie l'utilisateur final (le persona). Cela ancre la fonctionnalité dans une réalité d'usage.
• Quoi ? (Je souhaite...) : On décrit l'action ou la fonctionnalité attendue de manière claire.
• Pourquoi ? (Afin de...) : On exprime la valeur, le bénéfice pour l'utilisateur. C'est la partie la plus importante car elle justifie l'existence même de la story et aide à prendre des décisions de priorisation.

2. User Stories, Epics et Tâches : Ne pas tout mélanger

En tant que développeur, vous êtes habitué à décomposer le travail en tâches techniques. Il est crucial de bien situer la User Story par rapport à d'autres concepts agiles comme l'Epic et la Tâche.

Pour clarifier ces niveaux de granularité, je vous invite à lire la section suivante.

Pour résumer visuellement cette hiérarchie :

• Epic : Une grande fonctionnalité qui ne peut pas être réalisée en un seul Sprint. Ex: "Gestion du profil utilisateur".
• User Story : Un morceau de l'Epic, assez petit pour être réalisé en un Sprint. Ex: "En tant qu'utilisateur, je veux changer mon mot de passe...".
• Tâche : Une action technique concrète nécessaire pour réaliser une User Story. Ex: "Créer le endpoint de l'API pour la réinitialisation du mot de passe", "Intégrer la page de changement de mot de passe". Les tâches sont définies par les développeurs, souvent lors du Sprint Planning.

3. Les qualités d'une bonne User Story : L'acronyme INVEST

Le format seul ne suffit pas. Une User Story de qualité doit respecter certains principes, résumés par l'acronyme INVEST.

Voici un résumé de ces qualités :

• Independent (Indépendante) : La story doit pouvoir être développée et livrée sans dépendre d'une autre story.
• Negotiable (Négociable) : Elle n'est pas un contrat rigide. C'est un point de départ pour une discussion entre le PO et l'équipe.
• Valuable (Qui a de la valeur) : Elle doit apporter une valeur claire à l'utilisateur final ou au client.
• Estimable (Estimable) : L'équipe doit avoir assez d'informations pour pouvoir en estimer l'effort.
• Small (Petite / "Sized appropriately") : Elle doit être assez petite pour être terminée en un seul Sprint.
• Testable (Testable) : On doit pouvoir vérifier qu'elle est terminée et qu'elle fonctionne comme attendu. C'est là qu'interviennent les critères d'acceptation.

4. Rendre la User Story testable : Les Critères d'Acceptation

Si la User Story décrit le "pourquoi" et le "quoi", les Critères d'Acceptation (AC) décrivent le "comment ça doit marcher". Ils transforment une description narrative en une liste de conditions vérifiables. Pour l'équipe de développement, ils définissent les limites de la story et servent de base pour les tests.

Il est important de ne pas confondre Critères d'Acceptation et Definition of Done (DoD) que nous avons vue dans la leçon précédente :

• La DoD est une checklist de qualité générale, qui s'applique à toutes les User Stories (ex: "le code est revu", "les tests unitaires passent").
• Les Critères d'Acceptation sont des règles fonctionnelles spécifiques à une seule User Story.

Comment rédiger des Critères d'Acceptation ?

La méthode la plus utilisée dans les équipes agiles est le format Gherkin, qui s'appuie sur une structure Given/When/Then (ou en français Étant donné que / Lorsque / Alors).

• Étant donné que (Given) : Décrit le contexte initial, la situation de départ avant l'action.
• Lorsque (When) : Décrit l'action effectuée par l'utilisateur.
• Alors (Then) : Décrit le résultat attendu, la conséquence observable de l'action.

Ce format est très apprécié des développeurs car il correspond parfaitement à la structure d'un cas de test : Arrange / Act / Assert.

Voyons un exemple concret en vidéo.

5. À vous de jouer !

Mettons maintenant tout cela en pratique. Votre expérience de développeur web full-stack va être un atout pour imaginer les différents cas.

Scénario : Vous travaillez sur une plateforme de blog.

Votre mission : Rédigez une User Story complète (format "En tant que...") et ses critères d'acceptation (format "Étant donné que...") pour la fonctionnalité suivante : "un auteur veut pouvoir sauvegarder son article en cours de rédaction sans le publier, pour y revenir plus tard".

Conclusion

Aujourd'hui, nous avons appris à formuler des exigences de manière agile en utilisant les User Stories. C'est une compétence au carrefour de la technique, du produit et de l'humain.

Voici les points clés à retenir :

• La User Story capture le besoin d'un utilisateur avec le format "En tant que..., je souhaite..., afin de...", en se concentrant sur le Qui, le Quoi et le Pourquoi.
• Une bonne User Story respecte les critères INVEST : elle est notamment indépendante, petite et testable.
• Les Critères d'Acceptation rendent la story testable en décrivant les conditions de succès.
• Le format "Étant donné que..., Lorsque..., Alors..." (Gherkin) est une manière structurée et efficace de rédiger des critères d'acceptation qui parlent à la fois au métier et aux développeurs.

Maîtriser la rédaction de User Stories vous permettra de mieux comprendre les besoins, de faciliter les discussions au sein de l'équipe et de vous assurer que le développement est aligné sur la valeur attendue par l'utilisateur.

Dans notre prochaine leçon, nous verrons ce qu'il advient de toutes ces User Stories une fois qu'elles sont dans le Product Backlog. Nous aborderons un aspect essentiel du rôle de Product Owner : comment les classer ? Nous apprendrons à appliquer une technique de priorisation du Product Backlog. À bientôt