Comment rédiger une user story Agile : Templates + Exemples

Une user story est la carte d’identité des fonctionnalités à développer. Savoir la rédiger est une des compétences clés de l’application de la méthode agile.

Elle se distingue avec son approche centrée "utilisateurs", l’attention n’est plus focalisée sur la conception, mais sur la création d’une valeur réelle pour les clients.

Dans cet article, nous verrons, grâce à des exemples de user stories concrets, comment réussir à les rédiger.

Vous trouverez aussi des templates à remplir ou pour vous inspirer lors des prochaines préparations de votre backlog.  

User story : Définition

Une User story, ou récit utilisateur, est une description d’exigences pour toute fonctionnalité ou “tâche” nécessaire au fonctionnement du produit ou du service en développement. 

Les user stories :

• Sont écrites par le Product Owner de manière concise et ne concerne qu’une seule fonctionnalité à la fois
• Aident à faciliter l'exécution et la compréhension des tâches par les équipes
• Une fois rédigées, elles vont s’ajouter aux autres récits du produit et ensemble, elles constituent le “product backlog”. Il est en quelque sorte un réservoir de fonctionnalités à développer dans les prochaines itérations

Dans cet article, nous nous concentrerons sur les user stories agiles de l’approche Scrum mais pour Kanban, on utilise également ce concept de carte.

Qui rédige une user story ?

La rédaction d'une User Story, est généralement réalisée par :

• Le Product Owner dans le cadre du management en mode agile : C'est lui qui est le plus à même de comprendre les besoins et les attentes des utilisateurs du produit
• L'équipe de développement, les designers, les utilisateurs eux-mêmes ou toute autre partie prenante peuvent participer à la création des user stories : Dans cette dynamique, le Product Owner joue un rôle de facilitateur et de chef d'orchestre pour s'assurer que chaque histoire reflète fidèlement les besoins des utilisateurs.

En outre, l'Intelligence Artificielle Générative (IAG) améliore ce processus en analysant diverses données pour générer des User Stories reflétant fidèlement les attentes des clients.

Pourquoi faire ?

La user story constitue un excellent moyen pour définir votre produit avec clarté en :

• Aidant à articuler les fonctionnalités de votre produit en utilisant un vocabulaire simple, sans détails techniques
• Générant des discussions importantes au sujet du produit
• Permettant à la fois à l’équipe Scrum et aux parties prenantes externes de mettre en lumière les interrogations ou désaccords potentiels
• Aidant à clarifier les équipes sur le “quoi” construire, pour “qui”, “pourquoi” et “quand”, mais aussi à la communication du projet en dehors de l’équipe. Souvent, les développements des produits digitaux nécessitent un langage technique et complexe, impliquant beaucoup d’acronymes
• Favorisant la participation de personnes non techniques au projet

Mais quelles sont alors les règles d’écriture des user stories ?

Les règles d’écriture des User stories :

• Sont strictes et doivent être respectées
• Permettent de définir les avantages que votre produit apporte à ses utilisateurs. 

Voyons comment cela se passe.

Comment bien rédiger une user story ?

Avant de rédiger une user story, il est nécessaire de bien comprendre les besoins des utilisateurs. 

Des profils "Persona" vous aideront à comprendre le problème que le personnage veut voir résolu en utilisant le produit, et ce, à l'aide d'une conception visuelle.

Toutefois, notez qu'avant de créer votre carte de fonctionnalité, notamment si vous utilisez un software de management de projet Agile tel que Jira, il faut que vous définissiez si la carte est une user story, une épic, une tâche ou un bug. 

Etape 1 : Identifier les User stories, Epics, et tâches

Il s'agit de comprendre ce qui doit être créé : user stories, épics, tâches...

Afin de pouvoir bien qualifier le besoin, il est primordial de faire une différence entre :

1. Une Epic agile ou macro-user story : Elle représente un objectif d’action pour l’utilisateur. Si un récit utilisateur ne peut être développée par un membre de l’équipe en une itération, c'est qu’elle est trop complexe.
   Ce récit doit être transformé en Epic et celle-ci doit être re-découpée pour créer des user stories plus petites.
2. Une tâche : Est une action à réaliser parmi d’autres afin de pouvoir développer la user story.
   Les membres d’une équipe Scrum trouvent souvent plus facile de découper les récits en tâches techniques.
   Le processus de décomposition d’un récit en tâches aide également l’équipe de développement à mieux comprendre ce qui doit être fait.

Les epics, user stories et tâches sont différents au niveau de la granularité. 

Ajuster la granularité de son récit permet de trier et ordonner les user stories dans son backlog.

Exemple : Application bancaire.

Pour l'épic « authentification de l’utilisateur » :

Les user stories sont :

• US1 : Écran de connexion utilisateur.
• US2 : Processus du Mot de passe oublié.
• US3 : Verrouiller le compte après trop de tentatives infructueuses.

Pour la US1  « Écran de connexion utilisateur » :

Les tâches sont :

1. Conception de la page de connexion.
2. Couper les icônes et les images SVG. Implémenter la page de connexion HTML / CSS / JS.
3. Créer des scripts SQL pour créer des tables.
4. Créer une API de service Web pour les informations utilisateurs
5. etc…

Les bugs eux, sont des correctifs à apporter à une user story – développée, testée et rejetée – ou au produit en général suite à son mauvais fonctionnement.

Une fois que vous savez si vous devez créer un bug ou un récit et son niveau de granularité, vous pouvez entamer le processus de rédaction. 

Etape 2 :  Utiliser un Persona

Une excellente technique pour vos user stories consiste à travailler avec des Personas. 

Ce sont des personnages fictifs basés sur une connaissance profonde des utilisateurs de votre produit.

Pour vous familiariser avec vos utilisateurs, le persona représentatif doit être visuel. Il se compose généralement :

• D’un nom d’une image
• De ses caractéristiques
• De ses comportements
• D’un objectif

Son objectif doit représenter le problème que le personnage souhaite qu'il soit résolu en utilisant le produit.

Construire en équipe un Persona peut réellement aider à créer des épics et leurs user stories.

Reprenons l’exemple de l’application bancaire et un de ses Personas : 

Template d’un Personna

Voici le template utilisé vide. N’hésitez pas à le télécharger !

Une fois votre ou vos Personas créés, vous pouvez commencer à écrire vos US. 

• Elles doivent être concises et faciles à comprendre. 
• Il faut éviter les termes confus et ambigus et utiliser le présent. 
• Concentrez-vous sur ce qui est important pour le Persona concerné par votre US.

Etape 3 : Rédiger la US

Une user story se compose de :

• Un titre
• Le niveau de priorité
• L'estimation de l'user story
• Le format “En tant que”, “je souhaite”, “afin de”
• Les critères d'acceptation que je vous explique plus loin

Ainsi, le format “En tant que”, “je souhaite”, “afin de”, permet de poser les variables les plus importantes de la fonctionnalité :

• le Qui ? le Quoi ? et le Pourquoi ? 

En lisant une user story rédigée avec ce modèle, les développeurs ne peuvent pas faire de mauvaises interprétations. 

Les développements correspondront exactement aux exigences écrites. 

• En tant que,
• Je souhaite,
• Afin que,

Reprenons l’exemple de notre application bancaire et de notre Persona pour rédiger un exemple de user story :

Pour l'épic « authentification de l’utilisateur » ( US2 : Processus du Mot de passe oublié) :

En tant que utilisateur Untel, je souhaite pouvoir réinitialiser mon mot de passe oublié afin d’en recevoir un nouveau et d’accéder à mon espace personnel.

Etape 4 : Vérifier la qualité de la US

L'acronyme INVEST agile qui aide à retenir un ensemble de critères pour s’assurer de la qualité d’une user story. 

Si votre récit ne répond pas à l’un de ces critères, l’équipe peut vouloir la reformuler, ou même envisager une réécriture. 

Une bonne user story doit être :

• Indépendante des autres user stories :  elle doit pouvoir être développées indépendamment des autres récits du backlog pour éviter les blocages et embouteillages dans le processus.
  Si en prenant le récit, un développeur doit attendre qu’un autre récit soit mis en production, il va créer un goulet d’étranglement risquant un non-respect de l’engagement pris en début de sprint. 
• Négociable :  elle doit être assez flexible pour permettre à l’équipe d’échanger et de discuter.
• D’une grande valeur pour l’utilisateur : pour chaque récit développé et livré en fin d’itération, une valeur ajoutée doit être apportée au client. 
• Estimable : l’équipe Scrum doit toujours être en mesure de l’estimer lors de la cérémonie du sprint planning.
  Si l’équipe n’arrive pas à se mettre d’accord, la user story manque d’informations ou n’est pas suffisamment claire.
• D’une taille suffisamment petite (S pour Size) :  une User Story est plus facile à estimer, à comprendre et à développer si son découpage est réussi.
• Testable : certains critères qui vont définir si une user story développée est considérée comme terminée. Lorsqu’un utilisateur ne peut tester une fonctionnalité, cela pose une problématique.

Etape 5 : Ajouter les critères d’acceptation 

Une fois l’objectif de la user story rédigé, il faut y ajouter des critères d’acceptation. 

Ces critères :

• Vont compléter la User Story en décrivant la manière dans la fonctionnalité sera utilisée, et aussi les cas limites de son utilisation
• Rendent un récit testable et garantissent qu’elle peut être montrée aux utilisateurs et aux autres parties prenantes lors de la revue sprint.

Je vous conseille d’utiliser 3 à 5 critères d’acceptation pour votre user story. 

J’utilise aussi un certain modèle : 

• Étant donné que,
• Lorsque,
• Alors,

Si nous reprenons l’exemple de l’application bancaire, voici des exemples de critères d’acceptation :

Pour l'épic « authentification de l’utilisateur » ( US2 : Processus du Mot de passe oublié) :

• Étant donné que je suis sur la page de connexion, lorsque je clique sur “mot de passe oublié” alors je suis redirigé vers la page de réinitialisation du mot de passe
• Étant donné que je suis sur la page “réinitialiser mon mot de passe”, lorsque je rentre et que je valide mon identifiant, alors une vérification de mon identifiant m’informe si oui ou non il existe
• Étant donné que mon e-mail existe lorsque je valide mon identifiant, alors je reçois par sms mon nouveau mot de passe

Template user story 

Voici un template pour la rédaction d’une user story Agile.

En conclusion

Les règles d’écriture pour rédiger une user story Agile n’ont plus de secrets pour vous!

Mais attention, la partie la plus importante de la création d’un récit utilisateur n’est pas visible, car elle représente la communication avec l’équipe.

Il est très important que le Product Owner discute des récits avec l’équipe et que vous les affiniez ensemble.

Maintenant que la user story et bien rédigée, il faut alors l’estimer.

N’hésitez pas à me dire en commentaire, si les templates vous ont été utiles ! S’ils vous plaisent, je veillerai à en insérer dans les prochains articles.