User Story : Qu'est-ce que c'est ?

Qu'est-ce qu'une user story ?

Une user story (histoire utilisateur) est une technique de formulation des besoins logiciels issue de la méthodologie Extreme Programming (XP) et massivement adoptée par Scrum et les autres frameworks Agile. Elle décrit une fonctionnalité du point de vue de l'utilisateur final, en se concentrant sur la valeur apportée plutôt que sur les détails techniques d'implémentation. Le format canonique est : "En tant que [type d'utilisateur], je veux [action/fonctionnalité] afin de [bénéfice/objectif]".

La user story n'est pas une spécification technique détaillée : c'est une promesse de conversation. Elle capture l'intention et le besoin de manière suffisamment précise pour être estimée et planifiée, tout en laissant de la place à la discussion entre le product owner, l'équipe de développement et les parties prenantes. Cette souplesse est ce qui distingue la user story d'un cahier des charges classique et en fait un outil fondamental de la communication Agile.

Pourquoi la user story est importante

La user story résout un problème fondamental du développement logiciel : le fossé de communication entre ceux qui expriment les besoins et ceux qui les implémentent. En plaçant l'utilisateur final au centre de la formulation, elle force chaque partie prenante à penser en termes de valeur plutôt que de technique.

• Centrage utilisateur : La formulation "En tant que... je veux... afin de..." oblige à identifier qui bénéficie de la fonctionnalité et pourquoi, ce qui évite de développer des fonctionnalités sans valeur réelle.
• Conversation facilitée : La user story est un support de discussion, pas un document figé. Elle encourage le dialogue entre le product owner, l'équipe technique et les utilisateurs finaux.
• Estimation possible : Le format concis permet à l'équipe d'estimer la complexité en story points et de planifier les sprints de manière réaliste.
• Priorisation claire : Les user stories sont indépendantes les unes des autres, ce qui permet au product owner de les prioriser facilement en fonction de la valeur business.
• Testabilité : Les critères d'acceptation associés à chaque user story définissent clairement quand la fonctionnalité est terminée, ce qui élimine l'ambiguïté sur la "definition of done".
• Taille adaptée : Les user stories sont dimensionnées pour être réalisables en un sprint, ce qui facilite la planification et la livraison incrémentale.

Comment ça fonctionne

Une user story se compose de trois éléments, souvent résumés par les "3 C" : Card (carte), Conversation (discussion), Confirmation (validation). La carte est la description courte au format "En tant que... je veux... afin de...". La conversation est le dialogue entre le product owner et l'équipe pour clarifier les détails. La confirmation prend la forme des critères d'acceptation qui définissent quand la story est terminée.

Les critères d'acceptation sont essentiels. Ils transforment l'intention de la user story en conditions vérifiables. Par exemple, pour la story "En tant que client, je veux rechercher un produit par nom afin de trouver rapidement ce que je cherche", les critères d'acceptation pourraient être : "La recherche retourne des résultats en moins de 2 secondes", "Les résultats sont triés par pertinence", "La recherche fonctionne avec des fautes de frappe mineures".

L'estimation des user stories se fait généralement en story points à l'aide du Planning Poker. L'équipe évalue la complexité relative de chaque story (et non le temps) en utilisant une échelle de Fibonacci (1, 2, 3, 5, 8, 13, 21). Les stories estimées à plus de 13 points sont considérées comme des "epics" et doivent être découpées en stories plus petites.

Chez KERN-IT, nous utilisons un modèle de user story enrichi qui inclut systématiquement : le format standard, les critères d'acceptation, les notes techniques (contraintes d'implémentation), les maquettes associées (liens Figma) et la priorité business (MoSCoW : Must, Should, Could, Won't). Ce modèle garantit que chaque story est suffisamment détaillée pour être développée sans ambiguïté.

Exemple concret

Dans un projet de plateforme de recrutement développé par KERN-IT pour un client belge, voici un exemple de user story complète :

Story : En tant que recruteur, je veux filtrer les candidatures par compétences et expérience afin de présélectionner rapidement les profils pertinents pour un poste ouvert.

Critères d'acceptation : Le recruteur peut sélectionner une ou plusieurs compétences dans une liste prédéfinie. Le filtre par années d'expérience offre un curseur min/max. Les résultats se mettent à jour en temps réel sans rechargement de page. Les filtres actifs sont affichés sous forme de tags supprimables. La combinaison de filtres fonctionne en mode "ET" (toutes les conditions doivent être remplies). Le nombre de résultats correspondants est affiché en temps réel.

Cette story a été estimée à 5 story points par l'équipe et réalisée en 3 jours dans le sprint 4 du projet. Les critères d'acceptation ont servi de base aux tests d'acceptation automatisés.

Mise en oeuvre

1. Organiser un story mapping : Cartographier le parcours utilisateur complet et identifier les user stories nécessaires pour chaque étape. Cet exercice, souvent réalisé pendant le sprint 0, produit le backlog initial.
2. Appliquer le critère INVEST : Chaque user story doit être Indépendante, Négociable, Valable (apporte de la valeur), Estimable, Suffisamment petite (Small), Testable.
3. Rédiger les critères d'acceptation : Pour chaque story, lister les conditions concrètes et vérifiables qui définissent quand la story est terminée.
4. Estimer en équipe : Utiliser le Planning Poker pour que toute l'équipe évalue la complexité. Les divergences d'estimation révèlent souvent des malentendus à clarifier.
5. Découper les epics : Toute story estimée à plus de 13 points est un epic qui doit être découpé en stories plus petites, chacune livrable indépendamment.
6. Raffiner continuellement : Le backlog refinement (grooming) est une session régulière où l'équipe détaille et réestime les stories prévues pour les prochains sprints.

Technologies et outils associés

• Jira / Linear : Outils de gestion de backlog avec des templates de user stories, des champs de critères d'acceptation et des estimations en story points.
• Miro / FigJam : Outils de user story mapping visuel pour cartographier les parcours utilisateurs et identifier les stories.
• Figma : Outil de design pour les maquettes associées aux user stories, facilitant la communication visuelle avec l'équipe de développement.
• Planning Poker (apps) : Applications en ligne pour les sessions d'estimation en équipe (Scrum Poker, PlanITPoker).
• Cucumber / Gherkin : Frameworks de Behaviour-Driven Development (BDD) qui transforment les critères d'acceptation en tests automatisés exécutables.
• Notion : Outil de documentation pour les templates de user stories et le suivi des décisions produit.

Conclusion

La user story est l'atome du développement Agile : la plus petite unité de valeur livrable qui maintient le focus sur l'utilisateur final. Bien rédigée, avec des critères d'acceptation clairs, elle élimine l'ambiguïté, facilite la communication entre les parties prenantes et permet une planification fiable des sprints. Chez KERN-IT, nous investissons du temps dans la rédaction de user stories de qualité car nous savons par expérience qu'une story mal définie coûte bien plus cher en retravail qu'en temps de préparation. La user story n'est pas de la bureaucratie : c'est l'outil qui garantit que chaque ligne de code écrite apporte de la valeur réelle à l'utilisateur.