Fiche 05 : User Story

Une user story (appelée également " item " dans Scrum) décrit une fonctionnalité qui aura de la valeur aux yeux d'un utilisateur ou d'une partie prenante du système ou du produit. La user story comprend : un court titre descriptif ; le rôle qui émet l'exigence ; l'exigence ; le gain si l'exigence est atteinte. Les stories doivent être rédigées de telle manière que le propriétaire du produit puisse les comprendre et les prioriser.

Fiche descriptive des fonctionnalités du produit à réaliser

Pourquoi l'utiliser ?

Objectif

Décrire l'ensemble des fonctionnalités qui auront de la valeur aux yeux d'un utilisateur ou d'une partie prenante du système ou du produit.

Contexte

Les stories sont créées une première fois en début de projet, et mises à jour à chaque sprint.

Comment l'utiliser ?

Étapes

• Rédiger la story sous la forme : " En tant que , je veux , afin de " (ex : En tant qu'acheteur en ligne, je veux pouvoir ajouter des items à mon panier afin d'enregistrer mes achats que je ne souhaite pas acheter dans l'immédiat).
• Valider les 3C de la Story (Source : Ron Jeffries www.xprogramming.com). Carte : tient sur une carte de 10x15 cm (" un jeton représentant une exigence "). Conversation : " un échange d'idées, d'opinions et de sentiments ". Confirmation : critère d'acceptation SMART (Spécifique - explicitement défini, Mesurable - possible à observer et quantifier, Atteignable - possible à réaliser et à mettre en place, Réaliste - en rapport avec la Story, Temporel - quand pouvoir observer le résultat).
• Les développeurs doivent jouer un rôle actif en aidant à la définition des stories : en repérant les incohérences et les écarts entre les stories ; en utilisant les connaissances techniques pour créer de nouvelles stories qui semblent correspondre à la vision du propriétaire du produit ; en cherchant des stories alternatives qui seraient moins coûteuses à construire en termes de technologie ; en décomposant les stories afin de les rendre plus faciles à planifier ou à mettre en oeuvre.
• Piloter le cycle de vie de la Story : une story n'est estimée que si elle a été acceptée ; une story ne peut être planifiée que si elle est estimée ; une story ne peut devenir " encours " que si elle est planifiée ; une story passe normalement de " en cours " à " fini " à la fin d'un sprint.

Méthodologie et conseils

Une manière de rédiger les critères d'acceptation de la story, est la suivante : Doit contenir un acteur, un verbe et des résultats observables (ex : Si , lorsque , alors ).

Les stories peuvent être classées en 3 catégories différentes :

• user story : décrit ce que voit l'utilisateur, ce qui leur apporte de la valeur ou de l'utilité ;
• story technique : invisible pour les utilisateurs, mais bien visible de l'équipe de développement ; elle est indispensable pour pouvoir développer certaines user stories ;
• défaut : c'est quelque chose de visible de l'utilisateur, anomalie ou demande d'évolution du produit, et qu'il va falloir corriger.