Comment rédiger une bonne User Story

Une US est très simple d’apparence mais parfois difficile à rédiger. Justement, le tout est de réussir à rester simple tout en étant le plus complet possible.

comment-rédiger-une-bonne-user-story-agilaction

L’User story dans les méthodes agiles vient en alternative aux longues spécifications fonctionnelles que l’on retrouve dans les projets classiques. Elle consiste à capturer le besoin utilisateur et le décrire de manière très simple. La rédaction d’une US est sous la responsabilité du Product Owner. Il va d’abord recueillir le besoin des utilisateurs puis diviser cette demande en plusieurs épics (grands thèmes) qui seront eux même constitués de plusieurs Users Stories.

La ligne directrice

Dans une User Story on cherche à retranscrire très clairement le besoin utilisateur : ce qu’il veut pouvoir faire, pourquoi il souhaite le faire et surtout comment il souhaite le faire. Il ne s’agit pas uniquement de détailler l’aspect d’une fonctionnalité qu’on souhaite ajouter, il faut aussi se mettre dans la peau de l’utilisateur final.

Pour être sûr de couvrir toute la demande de client et le besoin utilisateur, au début de la rédaction de l’US il faut se servir d’une phrase très simple :

«  Afin de (raison) … En tant que (rôle de l’utilisateur) … je peux (le but) »

Par exemple : «  Afin de connaître les contrats d’un client, en tant que commercial je peux afficher tous les contrats d’un client sélectionné .»

Cette simple petite phrase va vous assurer de répondre au « qui, quoi et comment » pour les développeurs tout en restant orienté fonctionnel.

Le format et la taille

Le format lui aussi doit rester simple. Une US se présente sous la forme d’une fiche structurée. Elle doit être courte : une US ne doit pas être trop complexe, si elle est beaucoup trop complexe c’est qu’il faut la diviser en 2 voire trois (Comment diviser une US).

Elle est composée de plusieurs parties qui restent en général toujours les mêmes. En voici un exemple :

  • En début d’US on reprend la ligne directrice citée plus haut pour s’assurer de la suivre tout le long de celle-ci : «  Afin de (raison) … En tant que (rôle de l’utilisateur) … je peux (le but) »
  • La complexité : cette partie peut se situer à un autre endroit de l’US et peut être facultative. C’est la note qu’ont donné les développeurs à la complexité de cette fonctionnalité. Elle ne change en rien la rédaction de l’US mais permet d’être informé sur l’étendue de cette dernière et donc de mieux la comprendre .
  • Objectif : On rappelle ici l’objectif principal et global de cette fonctionnalité.
  • Description : On rentre dans le vif du sujet, ici on décrit clairement le schéma d’utilisation de la fonctionnalité. Les différentes étapes et les différents résultats de chaque action et dans l’ordre. On retrouvera donc la plupart du temps des « conditions » par exemple : «Lorsque je suis connecté, je peux sélectionner telle information »
  • Maquettes : Ici on retrouve les maquettes de ce que l’on veut retrouver à l’écran. Plusieurs maquettes sont en général nécessaires pour décrire ce qui s’affichera à chaque action. Bien évidemment on lie à ces maquettes des descriptions pour comprendre à quelles conditions on arrive à tel ou tel écran.
  • Tests fonctionnels : Enfin, cette partie permettra une fois l’US réalisée de la tester. On décrit précisément le test qui validera l’US . Indispensable pour assurer la qualité.

INVEST

Cette grille Invest va vous permettre de vérifier si votre US est de qualité, et si non de la modifier. Voici les critères qu’une User Story doit respecter :

I pour Independant :   Il faut que les User Stories soient totalement indépendantes les unes des autres (dans la mesure du possible bien sûr).

N pour Negotiable :    Chacune des US doit pouvoir être négociée et discutée lors des échanges  avec l’ensemble de l’équipe de développeurs pour s’assurer de la qualité de cette dernière.

V pour Valuable :        Elle doit avoir absolument de la valeur ! Que ce soit pour le client final ou pour l’utilisateur une US doit apporter de la valeur, c’est la seule raison de développer cette dernière. L’US doit être un résultat de la collaboration entre le client, l’utilisateur et l’équipe de développeurs.

E pour Estimable :      Elle est évaluée par l’ensemble des développeurs. Son évaluation se fait de manière relative : on estime une US en fonction de l’ensemble des autres pour déterminer sa valeur  et sa complexité.

S pour Small :             Critère non négociable : une US doit être petite. Elle ne doit pas être trop complexe pour permettre d’être réalisée (avec d’autres) lors d’une itération de 2 ou 3 semaines maximum. Si elle est votée à un niveau de complexité trop élevé, il est nécessaire de la  diviser en plusieurs US.

T pour Testable :        Pour assurer la qualité de l’US : elle doit absolument être testable. On doit pouvoir au minimum définir des critères d’acceptation de l’US et les vérifier.

 

 

Sources : Guide Agile Alliance , All about Agile 

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *