User Stories et Critères d'Acceptation Clairs

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.

Elle suit traditionnellement ce format :

En tant que < type d'utilisateur >, je veux < réaliser une action > afin de < bénéficier d'un résultat >.

• En tant que... : Définit le "Qui". Cela nous force à penser à nos utilisateurs et à leurs rôles spécifiques.
• Je veux... : Décrit le "Quoi". C'est l'action ou la fonctionnalité elle-même.
• Afin de... : Explique le "Pourquoi". C'est la partie la plus importante, car elle expose la valeur métier ou le bénéfice attendu. Omettre le "Pourquoi" transforme une User Story en une simple instruction, perdant tout le contexte qui guide les bonnes décisions de développement.

Une user story n'est pas une spécification technique détaillée. Son but est d'être un "prétexte à conversation" entre l'équipe de développement, le Product Owner et les parties prenantes.

Pour bien comprendre comment les user stories s'inscrivent dans la décomposition d'un projet, de la grande idée aux petites tâches, la vidéo suivante est un excellent point de départ.

Ce processus de décomposition peut être visualisé comme suit :

2. Les caractéristiques d'une bonne User Story : L'acronyme INVEST

Comment s'assurer qu'une User Story est bien formulée et prête pour le développement ? L'acronyme INVEST est un guide mnémotechnique très utilisé. Une bonne story doit être :

• Indépendante : Elle doit pouvoir être développée, testée et livrée sans dépendre d'une autre story dans le même sprint.
• Négociable : Une story n'est pas un contrat gravé dans le marbre. C'est un point de départ pour une discussion qui aboutira à la solution.
• Valorisable (Valuable) : Elle doit apporter une valeur perceptible à l'utilisateur final ou au client.
• Estimable : L'équipe de développement doit être capable d'estimer l'effort nécessaire pour la réaliser.
• Suffisamment petite (Small) : Elle doit être assez petite pour être terminée en un seul sprint (idéalement en quelques jours).
• Testable : On doit pouvoir vérifier qu'elle est terminée et qu'elle fonctionne comme attendu. C'est là que les critères d'acceptation entrent en jeu.

La vidéo de Thiga que nous avons commencée couvre très bien ce point.

3. Le cœur du sujet : Les Critères d'Acceptation

Si la User Story est le "Pourquoi", les critères d'acceptation (AC) sont le "Comment vérifier". Ils définissent les conditions qu'une fonctionnalité doit remplir pour être considérée comme terminée et acceptée par le Product Owner. Pour vous, développeur, ils constituent la définition du "fini" (Definition of Done) pour cette story.

Les ACs éliminent l'ambiguïté et servent de base pour les tests (manuels ou automatisés).

Il existe plusieurs formats, mais le plus efficace et le plus répandu est le format Gherkin. Il utilise une structure Given-When-Then (Étant donné - Quand - Alors).

• Given (Étant donné que) : Décrit le contexte initial, la situation de départ avant que l'action n'ait lieu.
• When (Quand) : Décrit l'action effectuée par l'utilisateur.
• Then (Alors) : Décrit le résultat attendu, le changement observable dans le système.

Pour approfondir ce format, je vous propose de lire un article très ciblé.

Pour voir comment tout cela s'assemble dans une User Story complète, nous allons regarder la dernière partie de la vidéo de Thiga.

Voici un exemple concret de ce à quoi cela ressemble dans un outil de gestion de projet :

4. Mise en pratique : Rédigeons les User Stories de "Chez Antoine"

Rappelez-vous les spécifications fonctionnelles que nous avons ébauchées pour le restaurant "Chez Antoine" dans la leçon précédente. Prenons deux fonctionnalités clés pour le client et transformons-les en User Stories complètes.

Fonctionnalités à transformer :

1. Le client peut consulter la carte des plats organisée par catégories.
2. Le client peut ajouter/modifier/supprimer des plats de son panier.

Votre mission : Prenez 15 minutes pour rédiger ces deux User Stories. Pour chacune, écrivez :

1. Un titre court et clair.
2. La User Story au format "En tant que..., je veux..., afin de...".
3. Au moins deux critères d'acceptation en format Gherkin (Étant donné que... Quand... Alors...), couvrant un cas "nominal" (où tout se passe bien) et un cas d'erreur ou un cas limite.

Une fois que vous avez terminé, comparez votre travail avec ma proposition ci-dessous.

Ma proposition

User Story 1 : Consultation de la carte

• Titre : Consulter la carte du restaurant

• User Story : En tant que client potentiel, je veux consulter la carte complète et organisée par catégories afin de découvrir l'offre du restaurant et choisir ce que je souhaite commander.

• Critères d'Acceptation :

  • Scénario : Affichage de la carte complète

    • Étant donné que je suis sur la page d'accueil du site "Chez Antoine"
    • Quand je clique sur le lien "Voir la carte"
    • Alors je suis redirigé vers la page du menu
    • Et je vois les plats regroupés par catégories : "Entrées", "Plats", "Desserts".
    • Et pour chaque plat, je vois son nom, son prix et une courte description.

  • Scénario : Un plat est temporairement indisponible

    • Étant donné que le gérant a marqué la "Mousse au chocolat" comme "indisponible"
    • Et que je consulte la catégorie "Desserts"
    • Quand je regarde la ligne de la "Mousse au chocolat"
    • Alors je vois une mention "Indisponible"
    • Et le bouton pour l'ajouter au panier est désactivé ou absent.

User Story 2 : Ajout d'un plat au panier

• Titre : Ajouter un plat au panier

• User Story : En tant que client, je veux ajouter un plat à mon panier afin de constituer ma commande avant de la valider.

• Critères d'Acceptation :

  • Scénario : Ajout d'un premier article au panier

    • Étant donné que je consulte la carte et que mon panier est vide
    • Quand je clique sur le bouton "Ajouter" à côté du plat "Pizza 4 fromages"
    • Alors l'icône du panier dans l'en-tête du site se met à jour pour afficher "1"
    • Et un message de confirmation "Pizza 4 fromages ajoutée au panier" apparaît brièvement.

  • Scénario : Ajout d'une quantité supplémentaire du même article

    • Étant donné que j'ai déjà une "Pizza 4 fromages" dans mon panier
    • Quand je clique à nouveau sur le bouton "Ajouter" à côté de la "Pizza 4 fromages"
    • Alors la quantité pour "Pizza 4 fromages" dans mon panier passe à 2
    • Et l'icône du panier affiche toujours le nombre total d'articles.

Note : L'article "20 Exemples d'histoires d'utilisateurs et bonnes pratiques" (ressource LINK) est une excellente source d'inspiration si vous souhaitez voir plus d'exemples variés.

Conclusion

Félicitations ! Vous savez maintenant comment traduire une exigence fonctionnelle en une User Story claire, concise et testable. Cette compétence est au cœur de la collaboration agile et garantit que l'équipe de développement et les parties prenantes partagent une compréhension commune de ce qui doit être construit.

Les points clés à retenir :

• La structure d'une User Story (En tant que, Je veux, Afin de) capture le qui, le quoi et surtout le pourquoi.
• L'acronyme INVEST est votre checklist pour garantir la qualité et la faisabilité de vos stories.
• Les critères d'acceptation, idéalement écrits en Gherkin, sont non négociables. Ils définissent précisément les conditions de succès et servent de contrat entre le Product Owner et l'équipe. Pour un développeur, ce sont les instructions de test avant même d'écrire la première ligne de code.

Maintenant que nous savons décomposer notre projet en petites unités de valeur estimables, la question logique suivante est : comment les estimer ? Dans la prochaine leçon, nous aborderons l'estimation de la charge de travail d'un projet en utilisant les story points, une technique agile qui permet de planifier et de suivre l'avancement d'un projet de manière collaborative et pragmatique.