Ce qui distingue un bon user story d'un mauvais, avec des exemples concrets

Le user story est devenu un format courant pour décrire un besoin dans un projet digital. Sa forme simple, « en tant que, je veux, afin de », cache pourtant une difficulté réelle. Un user story peut respecter cette structure tout en laissant une grande partie du besoin à interpréter. Les questions apparaissent alors pendant le développement, lorsque les décisions sont plus coûteuses à modifier.

Un exemple de mauvais user story

« En tant qu'utilisateur, je veux voir mes commandes, afin de suivre mes achats. »

Cette formulation semble correcte, mais elle ne dit presque rien d'utile. Qui est « l'utilisateur » : un client final, un employé du service client ou un gestionnaire de compte ? Que signifie « voir mes commandes » : une liste simple, un statut détaillé ou un historique complet ? Sur quelle période ? Que se passe-t-il s'il n'y a aucune commande, si une commande a été annulée ou si certaines informations ne sont pas disponibles ?

Rien de tout cela n'est précisé. L'équipe technique devra donc poser des questions ou prendre elle-même certaines décisions. Deux personnes pourraient ainsi interpréter le même user story de manière différente.

Le même besoin, mieux formulé

« En tant que client ayant passé au moins une commande, je veux voir mes dix dernières commandes avec leur statut actuel, afin de savoir si je dois encore agir sur l'une d'elles. »

Cette version précise le rôle concerné, ce qui doit être affiché et pourquoi cette information est utile. Elle ne décrit pas encore l'écran, la couleur des éléments ou la technologie utilisée. Elle donne en revanche suffisamment de contexte pour discuter de la solution et identifier les points qui doivent encore être précisés.

Les critères d'acceptation peuvent ensuite compléter le user story : les commandes sont affichées de la plus récente à la plus ancienne, seules les dix dernières sont affichées, le statut correspond à l'état actuel de la commande et un message spécifique apparaît lorsqu'aucune commande n'existe.

Le résultat est plus facile à développer, mais surtout plus facile à vérifier avec l'équipe métier.

Ce qui rend un user story réellement utilisable

Il précise le rôle concerné, plutôt qu'une catégorie trop large. « Utilisateur » cache souvent plusieurs profils qui n'ont ni les mêmes besoins ni les mêmes droits.

Il décrit un besoin et son intention. La partie « afin de » n'est pas décorative : elle permet de comprendre pourquoi la demande existe et d'éviter de construire une fonctionnalité dont l'utilité réelle n'est pas claire.

Il est accompagné de critères d'acceptation. Ce sont les conditions concrètes qui permettent de vérifier si le résultat correspond au besoin. Sans ces critères, la validation repose facilement sur une impression générale ou sur des interprétations différentes entre les personnes impliquées.

Il tient compte des cas limites pertinents. Que se passe-t-il si la liste est vide, si une donnée manque ou si l'action échoue ? Tous les cas possibles ne doivent pas être documentés, mais ceux qui peuvent modifier le comportement attendu doivent être identifiés.

Enfin, il reste centré sur le besoin plutôt que sur l'interface. « Je veux un bouton rouge en haut à droite » décrit déjà une solution. Le besoin pourrait être « je veux pouvoir annuler ma demande avant sa validation ». La manière de permettre cette action peut ensuite être discutée avec l'équipe produit et l'équipe technique.

Une erreur fréquente à éviter

Écrire des user stories trop larges, qui regroupent en réalité plusieurs besoins différents.

« En tant que gestionnaire, je veux gérer les commandes » peut sembler pratique, mais cette demande cache probablement plusieurs actions : consulter une commande, la modifier, l'annuler, exporter les données ou changer son statut. Chacune peut avoir ses propres règles, ses propres droits et ses propres cas particuliers.

Séparer ces besoins en plusieurs user stories permet de les comprendre, de les prioriser, de les développer et de les tester plus facilement. Le découpage ne doit cependant pas être mécanique : l'objectif n'est pas de créer le plus grand nombre possible de tickets, mais de rendre chaque besoin suffisamment clair pour pouvoir être discuté et validé.

En résumé

Un bon user story ne se reconnaît pas uniquement à sa forme. Il permet de comprendre qui a un besoin, ce qu'il cherche à accomplir et pourquoi, puis de vérifier concrètement si la solution répond à ce besoin. Les critères d'acceptation et les cas particuliers complètent cette description lorsque c'est nécessaire. Le temps investi à clarifier ces éléments en amont évite surtout que l'équipe technique et le métier prennent des décisions différentes sur ce qui devait être construit.