À retenir
- Il se focalise sur l'utilisateur final et non sur la technique.
- Il suit généralement le format : Rôle + Action + Bénéfice.
- Il sert de point de départ à une discussion entre l'équipe technique et le client.
C'est une description courte et simple d'une fonctionnalité, rédigée du point de vue de la personne qui va l'utiliser. Imaginez un petit mémo qui explique qui veut quoi et surtout pourquoi, afin que les développeurs comprennent l'objectif réel derrière une demande technique.
Étymologie
Traduction directe de l'anglais User Story. Ce concept a émergé avec les méthodes agiles à la fin des années 1990, principalement via l'Extreme Programming (XP), pour privilégier la communication orale et la compréhension des besoins sur la documentation technique exhaustive.
Exemples d'usage
- « En tant qu'abonné, je souhaite réinitialiser mon mot de passe par email afin de retrouver l'accès à mon compte si je l'oublie. »
- « En tant que gestionnaire de stock, je veux recevoir une alerte quand un produit est presque épuisé pour éviter les ruptures de stock. »
Cas d'usage
On utilise le récit utilisateur dans la gestion de projet agile (Scrum, Kanban) pour définir les tâches à accomplir lors du développement d'un logiciel, d'un site web ou d'une application mobile.
Bonnes pratiques
Respecter la règle INVEST : un récit doit être Indépendant, Négociable, apporter de la Valeur, être Estimable, Small (petit) et Testable. Il faut surtout éviter d'y inclure des détails techniques (comme le nom d'une table en base de données) pour se concentrer sur le besoin métier.
Synonymes
Antonymes
Conseil
Pour bien débuter, ne cherchez pas la perfection rédactionnelle. L'essentiel est que le développeur comprenne le problème que l'utilisateur cherche à résoudre. Si votre récit est trop long à lire, c'est qu'il est probablement trop complexe : divisez-le !
Questions fréquentes
Quelle est la différence avec un cas d'utilisation (Use Case) ?
Le récit utilisateur est plus court, moins formel et centré sur la valeur métier, tandis que le cas d'utilisation détaille souvent chaque étape de l'interaction avec le système.
Un récit utilisateur peut-il être trop grand ?
Oui, on l'appelle alors une 'Épique' (Epic). Il doit alors être découpé en plusieurs récits plus petits pour être réalisable en quelques jours.
Qui valide qu'un récit est terminé ?
Le Product Owner (responsable du produit) vérifie que les critères d'acceptation définis dans le récit sont bien respectés.