Les User Stories font partie de ces pratiques agiles qui ont largement été adoptées par la plupart des équipes agiles ou à peu près. Cette pratique se retrouve au cœur des backlogs produit qu’ils soient physiques ou numériques (Jira ou Azure Board ou autre). Le terme User Story est tellement popularisé que quasiment tous les Product Owner se retrouvent à vouloir (devoir ?) utiliser cet outil. Parmi les personnes que je rencontre et accompagne, j’en croise beaucoup qui n’ont pas été sensibilisées aux principes de base des User Stories. En les connaissant, vous allez passer d’un simple format d’écriture à un outil essentiel de votre expression de besoins.
Dans cet article, je vous propose de revoir l’essentiel à connaître sur les User Stories. Et si vous souhaitez améliorer votre pratique, je vous recommande notre e-learning dédié à cette thématique : “ChatGPT au service de vos User Stories“
Pourquoi les User Stories ?
Maîtriser la rédaction des User Stories n’est pas une question de suivi des bonnes pratiques. C’est d’abord comprendre les besoins des utilisateurs, leurs interactions avec votre produit et ce qu’ils en attendent. Cette compréhension doit être transmissible et compréhensible par des populations qui seront plus éloignées des utilisateurs finaux, comme on le voit souvent avec des équipes informatiques par exemple.
Les User Stories sont donc avant toute chose un outil conçu pour fluidifier et augmenter la probabilité que ceux qui veulent et ceux qui font se comprennent le mieux possible.
Comprendre le concept de User Story
Définition et structure
User Story se traduit littéralement par “Histoire utilisateur” en français. Une User Story raconte donc une histoire du point de vue de l’utilisateur (final). Concrètement c’est une brève description d’une interaction avec le produit du point de vue de l‘utilisateur final. Ce début de définition nous amène alors à devoir comprendre :
- Qui est l’utilisateur : sa fonction, sa catégorie, son métier…
- L’action qu’il mène avec le produit
Et pour que cette histoire ait un sens, il sera sans doute essentiel de comprendre pourquoi l’utilisateur final veut mener cette action, c’est là que la notion d’impacts (ou de bénéfices) émerge.
Ces 3 notions se retrouvent dans le format standard d’écriture des User Stories :
- EN TANT QUE [UTILISATEUR FINAL]
- JE VEUX [MENER UNE ACTION]
- AFIN DE [OBTENIR UN BÉNÉFICE/UN IMPACT]
Une User Story est donc rédigée en langage naturel, sans inclure de détails techniques. C’est pour cette raison que le format User Story est si puissant : il est compréhensible par tous les membres du projet qui parlent la même langue. Cette structure simple aide à clarifier le besoin sans s’enliser dans les détails techniques.
Prenons un exemple dans le secteur e-commerce. Une User Story pourrait être :
TITRE Gestion Multi-Adresses pour Clients Réguliers
EN TANT QUE client régulier
JE VEUX sauvegarder plusieurs adresses de livraison
AFIN DE faciliter mes achats futurs
Si vous découvrez ce format d’écriture, vous aurez remarqué qu’il est volontairement court. C’est le premier principe de la règle des 3C : Carte. Une User Story était historiquement rédigée sur une carte assez petite, un format A6 ou un Post-It large. Depuis l’explosion des outils numériques, cette exigence est plus difficile à maintenir car les champs de texte autorisent de long texte. Pourtant, une User Story devrait toujours être rédigée sur une carte.
Éléments clés pour un bon début de User Story
Voici les éléments à intégrer pour garantir que la User Story soit claire et utile tant pour l’équipe de réalisation que pour les parties prenantes. L’objectif est de rédiger une User Story qui est axée sur les besoins et les bénéfices de l’utilisateur :
- Titre : Le titre d’une user story est succinct mais descriptif. Il offre un aperçu rapide du besoin qu’elle couvre. Exemple : “Gestion Multi-Adresses pour Clients Réguliers”.
- Utilisateur final (ou rôle ou personnage) : définit qui est l’utilisateur concerné par l’interaction. Il aide à contextualiser la demande, à comprendre le profil de la personne demandeuse et à se concentrer sur les besoins spécifiques de cet utilisateur. Exemple : Client régulier
- Action (ou interaction) : décrit ce que l’utilisateur veut faire, ce qui est généralement une action ou une fonctionnalité spécifique. Exemple : Sauvegarder plusieurs adresses
- Bénéfice (ou valeur ou impact) : explique pourquoi cette fonctionnalité est importante pour l’utilisateur, ce qui aide à justifier la demande et à comprendre l’intention recherchée. Exemple : Faciliter les achats futurs
User Story vs. spécification technique
(ou User Story Technique ou Technical Story)
Contrairement à une spécification technique qui détaillerait “comment” une fonctionnalité serait implémentée, la User Story reste centrée sur le “quoi” et le “pourquoi”. Elles ne sont pas des listes de tâches techniques. Elles sont le pont entre les besoins de l’utilisateur et les solutions techniques.
C’est pour cela que les User Stories techniques n’existent pas (traduisez : histoire utilisateur technique, ce qui n’a aucun sens) . Ce qui n’empêche pas les équipes d’avoir besoin de voir apparaître dans le Backlog des demandes techniques. Je vous encourage alors à travailler plutôt avec un autre outil que les User Stories techniques pour tout ce qui porte sur les corrections de bugs, les exigences non-fonctionnelles ou la dette (technique ou métier).
Vers une User Story complète avec la Définition de Terminé
Une User Story n’est pas prête s’il lui manque sa Définition de Terminé, c’est-à-dire qu’en plus des éléments vus précédemment, une User Story est accompagnée de cas de tests (nominaux, en erreur et aux limites), qui explicitent de manière concrète comment cette User Story sera vérifiée (et donc considérée comme terminée.
C’est le deuxième principe de la règle des 3C : Confirmation.
Certaines personnes comprennent mieux la notion de Définition de Terminé lorsqu’on parle de cas de tests précis avec des vrais jeux de données. Cette exigence d’apporter des critères d’acceptation clairs et sans ambiguïté amène une qualité de travail considérable : le besoin est illustré par de vrais exemples qui seront utilisés dans l’implémentation des cas de test par l’équipe technique. Parfois, l’expertise présente va jusqu’à l’utilisation de format encore plus puissant comme Gherkin.
- Cas Nominal :
-
- Un client (ex : Jean Dupont, e-mail : jean.dupont@email.com) se connecte, accède à son profil, ajoute deux adresses de livraison (ex : 10 Rue de Paris, 75001 Paris et 20 Rue de Lyon, 69000 Lyon), et les sauvegarde avec succès.
-
- Cas en Erreur :
-
- Si une adresse est incomplète (ex : manque de code postal), un message d’erreur clair s’affiche pour guider l’utilisateur (ex : “Le code postal est manquant”).
-
- Cas aux Limites :
- Test de limite sur le nombre d’adresses sauvegardées (ex : un client essaie de sauvegarder plus de 5 adresses, la 6ème adresse déclenche un message d’alerte indiquant la limite atteinte).
- Test de Validation :
- Les tests automatisés vérifient que les clients peuvent sauvegarder, modifier, et supprimer plusieurs adresses.
- Les tests manuels sont réalisés pour assurer la fluidité de l’expérience utilisateur.
- Performance et Sécurité :
- La fonctionnalité répond aux exigences de performance et de sécurité du site.
- Les données des adresses sont stockées et traitées de manière sécurisée.
- Documentation :
- La documentation utilisateur est mise à jour pour inclure les instructions sur la gestion des adresses multiples.
Vers une User Story vivante
Le 3ème et dernier principe de la règle des 3C est : Conversation. Une User Story telle que nous l’avons décrite sera rarement le fruit d’une réflexion d’un Product Owner seul dans son bureau. C’est d’abord et avant toute chose un travail de dialogue, de discussions et de conversations entre les membres de l’équipe.
Cette notion d’élaboration collaborative des User Stories est souvent négligée au profit du livrable que nous avons vu juste avant. Manque de temps, d’intérêt ou de connaissance pour savoir diriger ces conversations sont les principales raisons qui font que bien des équipes se retrouvent avec des User Stories qui n’ont pas de valeur ajoutée par rapport à d’autres formats de spécifications fonctionnelles (comme les Use Case par exemple). Les User Stories se discutent toujours. Il revient au Product Owner et au Maître Agile a minima de s’assurer que ces conversations ont lieu, régulièrement et de manière récurrente.
Bonnes pratiques de rédaction des User Stories
La liste des bonnes pratiques est longue et les subtilités nombreuses. Néanmoins, voici une sélection de bonnes pratiques à appliquer les yeux fermés.
1. Bien connaître ses utilisateurs
Une compréhension claire du projet et des besoins des utilisateurs est essentielle. Cela implique des recherches utilisateurs, des personas bien définis souvent par des entrevues ou des ateliers du type Customer Journey, Empathy Map, Impact Mapping ou User Story Mapping par exemple.
2. Rester centré sur l'expérience utilisateur
Par exemple, une User Story d’une application de covoiturage pourrait être : “En tant que conducteur, je veux recevoir des notifications personnalisées de trajets alternatifs à proximité,
afin d’optimiser mes trajets”. La définition de Terminé porterait sans doute sur des critères spécifiques tels que la durée, la distance, ou les conditions de circulation actuelles.
Mauvaises Pratiques : Rédiger des User Stories trop techniques, par exemple, “En tant que conducteur, je veux une fonction de géolocalisation afin de détecter les trajets.” Ce type de formulation se concentre plus sur la solution technique que sur le besoin de l’utilisateur.
Ou encore “En tant que conducteur, je veux cliquer sur un nouveau trajet afin de changer de trajet” qui est une formulation trop centrée sur l’interface plus que l’interaction en tant que telle.
3. Utiliser les User Stories pour ce qu'elles sont
Il existe une quantité de formats considérablement plus adaptés pour décrire d’autres besoins sur un produit. Je suis particulièrement fan de l’approche FURPS+ (les exigences non-fonctionnelles dans le processus unifié #vieuxRoutardDesSpecs. Ou encore les system Story ou les Job Story ou même des formats Ad Hoc.
Tout ne rentre pas dans une User Stories car ce n’est pas un outil de travail qui a un caractère universel.
Le guide des User Stories étape par étape
Voici un petit récapitulatif des étapes à suivre pour arriver à une bonne User Story. La bonne nouvelle c’est que vous pouvez démarrer à partir de n’importe quelle étape. L’essentiel est de toutes les couvrir.
- Étape A – Identification du Besoin : Par exemple, lors d’un atelier, les utilisateurs d’une application bancaire expriment le besoin de visualiser rapidement leur solde principal
- Étape B – Définition du Rôle : “En tant que titulaire de compte”
- Étape C – Formulation de la demande : “Je veux consulter mon solde actuel”
- Étape D – Clarification du Bénéfice : “Afin de gérer mes finances plus efficacement”
- Étape E – Itérer autant de fois que nécessaire : pour être certain que tout le monde partage bien l’intention
- Étape F – Etablir la Définition de Terminé : pour être certain que tout le monde partage bien quels cas concrets la User Story devra supporter pour être considérée comme terminée.
Gagner du temps et de la qualité pour ses US
Il est désormais temps de passer à la pratique. Si vous vous posez des questions sur la qualité de vos User Stories, que vous y passez trop de temps à votre goût ou tout simplement que vous êtes à la recherche de moyens de faire mieux, nous avons créé un e-learning dédié : “ChatGPT au service de vos User Stories”.
Cet e-learning vous amènera à vous interroger sur la manière dont sont élaborées vos User Stories. Grâce à ChatGPT, vous bénéficierez d’un assistant de choix pour progresser en totale autonomie.
Ce sont encore les participants des précédentes sessions qui en parlent le mieux.
Apprenez à créer des User Stories précises, complètes et cohérentes grâce à l’IA. Gagnez du temps dans la rédaction avec des prompts efficaces.
L’art de rédiger des User Stories efficaces repose sur une compréhension approfondie des besoins de l’utilisateur et une capacité à traduire ces besoins en des histoires claires, concises et centrées sur l’humain. C’est une compétence qui va au-delà de la simple maîtrise des outils ou des formats ; c’est une approche qui nécessite empathie, précision et créativité. Les User Stories ne sont pas seulement des items dans un backlog, elles sont le cœur de la communication entre ceux qui imaginent et ceux qui réalisent, un pont entre le besoin utilisateur et la réalité technique.
En suivant les bonnes pratiques énoncées, en évitant les pièges des formulations trop techniques ou génériques, et en engageant toute l’équipe dans un processus de création collaborative, vos User Stories deviendront un puissant levier pour le succès de vos projets.
