Rédiger une User Story

© Photo de Kaleidico sur Unsplash

Qu'est-ce qu'une User Story ?

En méthodologie agile, il est proposé de définir son besoin fonctionnel sous forme de récit utilisateur (a.k.a. User Story ou US). C'est une description simple et concise d'une fonctionnalité ou d'un besoin utilisateur. Elle est structurée de la façon suivante : une narration accompagnée de tests d'acceptation.

Une US peut être rédigée sur n'importe quel outil de suivi de projet et l'ensemble de vos US forme le backlog de votre projet. 

Le nom d'une US est important pour une meilleure compréhension de votre backlog. Il faut éviter les noms similaires, les noms trop longs ou qui n'ont pas de rapport avec le détail.

La narration

C'est une phrase simple, écrite dans le langage de tous les jours pour décrire le besoin. Par exemple :

 
En tant que tel type d'utilisateur je veux faire telle action afin de remplir tel objectif.
 

Un exemple concret :

 
En tant qu'utilisateur connecté à l'admin dans la liste des clients, je veux pouvoir rechercher mes clients par leur nom de famille afin de les retrouver dans la liste.
 

Les tests d'acceptation

Chaque US doit être enrichie avec des scénarios de tests. Cela permet d'anticiper tous les cas possibles avant de démarrer les développements.

L'écriture de ces scénarios facilite la tâche du Product Owner lors de la phase de recette et peut aussi être utilisée par les développeur.se.s pour constituer des tests fonctionnels et ainsi pérenniser l'application pour éviter les régressions.

Voici un exemple d'écriture des scénarios en langage Gherkin. Ce langage permet de définir un contexte de départ, d'identifier l'action réalisée et de déterminer le résultat attendu. Par exemple :

 
Etant donné que (Given) mon contexte est celui-là
Quand (When) je fais cette action
Alors (Then) il se passe cette conséquence
 

Pour notre exemple concret : 

Scénario 1 : Recherche avec plusieurs résultats

 
Etant donné que j'ai 3 clients en BDD

• client 1 avec le nom Robert
• client 2 avec le nom Dupont
• client 3 avec le nom Roduque
  Quand je recherche la chaine de caractère "du" dans la liste
  Alors j'ai 2 résultats
• client 2 avec le nom Dupont
• client 3 avec le nom Roduque
   

Scénario 2 : Recherche avec un résultat unique

 
Etant donné que j'ai 3 clients en BDD

• client 1 avec le nom Robert
• client 2 avec le nom Dupont
• client 3 avec le nom Roduque
  Quand je recherche la chaine de caractère "dup" dans la liste
  Alors j'ai 1 résultat
• client 2 avec le nom Dupont
   

Scénario 3 : Recherche avec aucun résultat

 
Etant donné que j'ai 3 clients en BDD

• client 1 avec le nom Robert
• client 2 avec le nom Dupont
• client 3 avec le nom Roduque
  Quand je recherche la chaine de caractère "Dupond" dans la liste
  Alors j'ai 0 résultat et un texte qui indique : Aucun client ne correspond à votre recherche
   

Associer un titre pour chaque scénario facilite la compréhension des tests d'acceptation.

Les liens

Dans certains contextes, il sera nécessaire d'ajouter des liens supplémentaires à votre US. Par exemple :

• un lien vers une documentation technique externe
• un lien vers une autre User Story
• un lien vers une maquette graphique
• un jeu de données de test (c'est idéal)

N'hésitez pas à lier tout ce qui peut apporter à la compréhension du besoin pour les développeur.se.s.

Les questions à se poser concernant une User Story

Est-ce que mon US est indépendant ?
Une user story doit pouvoir être développée sans être dépendante d'autres users stories. Il sera nécessaire de bien prioriser la réalisation de ces dernières pour cela.

Est-ce que mon US décrit bien le besoin fonctionnel et pas technique ?
Vous devez vous positionner en tant qu'utilisateur et non développeur.

Est-ce que j'ai su me remettre en question sur cette user story ?
Restez ouvert quand vous présentez une user story à l'équipe de développement pour qu'elle puisse challenger le besoin fonctionnel et peut-être vous apporter des idées auxquelles vous n'avez pas pensé.

Est-ce que mon US n'est pas trop grosse ?
Il y a deux indicateurs concernant le calibrage d'une US :

• S'il est nécessaire d'écrire plus de 6 tests d'acceptations pour couvrir tous les cas de mon US il faut envisager de la redécouper
• Si lors de l'exercice de chiffrage, l'échelle choisie ne semble pas assez grande selon l'équipe de développement pour couvrir cette US il faut envisager de la redécouper

Pour conclure

L'exercice d'écriture de User Stories n'est pas un exercice simple, il faut un peu de pratique pour se sentir à l'aise. Il est important d'écouter les retours de l'équipe de développement pour faire évoluer la façon dont ces dernières sont rédigées et gagner en efficacité tout au long du développement de votre projet.