Qu'est-ce qu'une user story ? Définition et exemple

La phrase

Elle suit presque toujours le même modèle : « En tant que [acteur], je veux [action] afin de [bénéfice] ».

• L'acteur dit qui a le besoin : un client, un vendeur, un administrateur. Pas « l'utilisateur » quand on peut être plus précis.
• L'action dit ce qu'il veut faire, avec ses mots à lui, pas ceux du développeur.
• Le bénéfice dit pourquoi. C'est lui qui permet de trancher quand deux stories se contredisent ou qu'il faut en couper une.

Ce qu'on ajoute autour

• Un code (US01, US02…) pour s'y référer.
• Une priorité (haute, moyenne, basse) et une estimation (2 h, 3 jours, des points).
• Les conditions : ce qui doit être vrai avant (préconditions) et après (postconditions).
• Le scénario principal, étape par étape, entre l'utilisateur et le système, puis les scénarios alternatifs.
• Les tests d'acceptation : une action et le résultat attendu. Tant qu'ils ne passent pas, la story n'est pas finie.

Un exemple

La boutique en ligne de la page MCD.

US03 · Passer une commande. En tant que client, je veux valider mon panier afin de recevoir mes produits chez moi. Priorité haute, estimation 3 jours.

• Précondition : le client est connecté et son panier n'est pas vide.
• Scénario principal : le client valide son panier. Le système affiche le total et demande l'adresse. Le client la saisit et paie. Le système enregistre la commande et envoie un e-mail de confirmation.
• Scénario alternatif : le paiement est refusé. Le système le dit et garde le panier.
• Test : panier de 2 produits, paiement accepté. Résultat attendu : une commande de 2 lignes, au statut « payée ».

Les noms de la story donnent souvent des entités du MCD (Client, Commande, Produit), et ses verbes des associations.

Une bonne story

On résume souvent les qualités d'une story par INVEST : Indépendante, Négociable, de Valeur pour l'utilisateur, Estimable, Suffisamment petite (Small) et Testable. Une story qu'on ne sait pas estimer est souvent trop grosse : découpe-la.

User story et cas d'utilisation

Les deux décrivent ce que fait le système, à des niveaux différents. La story est un besoin précis et court. Le cas d'utilisation regroupe plusieurs stories autour d'un même but de l'acteur, sur un diagramme. Passer une commande est un cas ; valider son panier, saisir une adresse de livraison ou utiliser un code promo en sont des stories.

Dans l'éditeur de macgram, l'écran User stories garde le modèle « En tant que… je veux… afin de », les scénarios et les tests en tableaux, et copie tout en Markdown. Chaque story se rattache à son cas d'utilisation, et l'onglet À vérifier signale une story sans cas ou un acteur oublié.