Rédiger des User Stories de qualité en 3 étapes simples

On entend beaucoup parler de user stories (US) et on peut parfois se perdre au fil des articles ou au vu des différentes règles et frameworks. Selon nous, le plus important est de comprendre l’essence même d’une US, de se fixer un cap et de s’y tenir. Le reste n’est que manière de faire. Pour t’aider dans ta montée en connaissance sur le sujet, nous te donnons un aperçu des méthodologies et bonnes pratiques à suivre pour rédiger tes premières user stories.  Voici nos conseils en 2 mantras (se concentrer sur la valeur et aligner les équipes) et 3 étapes (délimiter, rédiger, discuter) pour rédiger des user stories de qualité et pertinentes.
‍

Garder la vision : le pourquoi du comment de tes user stories (US)

Si tu rédiges des US, c’est que les notions de valeur et vision sont devenues tes deux leitmotivs, et que tu en es le/la gardien.ne.
Une fois cette « évidence » posée, il s’agit de savoir comment garder ces deux principes au cœur de la rédaction de tes US.  
A savoir : l’US est le plus petit item de la méthode agile, le plus spécifique.  
Voici donc notre 1er conseil : toujours revenir aux bases. Pourquoi dois-je rédiger des US, à quoi et à qui serviront-elles ?

Comme la plupart des outils et des méthodes agiles, le concept de User Story naît des besoins et des freins constatés sur un projet d’envergure. Elle répond aux questions :  

• Comment s’assurer que l’ensemble des équipes parlent le même langage tout au long du développement du produit ?
• Comment garantir que l’essence des fonctionnalités à développer ne se perde pas dans un ensemble de spécifications techniques ?

Nous te résumons les enseignements de dizaines de livres et autres articles en 2 mantras clés qui doivent te guider à chaque US.

MANTRA #1 : une US se concentre sur la valeur apportée à l’utilisateur

Ton User Story doit décrire brièvement ce qu’un personnage veut, pourquoi et quelle fonctionnalité lui apporte de la valeur en répondant à ce besoin. Pas le temps de se perdre dans les détails ou autre spécification fonctionnelle qui risquent de t’éloigner de la fonctionnalité qui répond à ce que l’utilisateur veut vraiment.

MANTRA#2 : une US permet d'aligner les équipes

Chaque membre de la squad a ses bagages et sa grille de lecture, ce qui peut parfois créer des malentendus et décalages dans la création d’une nouvelle fonctionnalité. S’efforcer de discuter ensemble de la fonctionnalité permet de s’assurer que tout le monde comprend la même chose, et même de l’enrichir avec les apports de chacun. Ce n’est pas un hasard si le concept est né sous la forme de « Story » : quoi de mieux qu’une histoire commune pour aligner tout le monde et créer la discussion ? La discussion va aussi au-delà de l’équipe et s’applique à l’utilisateur : si tu le peux, discute avec lui pour être sûr d’avoir bien compris son besoin.  

La leçon principale à en tirer est qu’il n’existe pas de modèle universel et immuable d’US, mais plutôt des principes de travail à appliquer : c’est alors à l’équipe de définir les modalités qui lui conviennent le mieux. Pas de panique, un ensemble de règles de rédaction viennent t’aider. Cependant, garde bien ces 2 mantras en tête au moment d’appliquer les règles ! Si une US s’en éloigne, tu dois probablement ajuster ta méthode de rédaction.

S’appuyer sur les règles de rédaction qui te conviennent en 3 étapes :  

Définir le périmètre de ton user story (US)  

Bien découper l'idée métier.
La user story doit être le plus petit item de ton backlog produit. Il s’agit de fragmenter l’idée métier en un ensemble de petites fonctionnalités réalisables en une itération. C’est un exercice assez difficile : n’aie pas peur de découper tes US de manière très fine. Demande-toi toujours si ton US peut être réalisée par une personne au cours d’une itération. Si la réponse est non : découpe !

Assure-toi que ton US réponde à un problème et n'est pas trop générique.  

Revient toujours aux bases ! Voici une petite check-list des questions à se poser avant de démarrer :

• QUI : Qui est à l’origine du besoin (qui a demandé / qui profitera de la fonctionnalité ? Auprès de qui ai-je besoin de récolter du feedback pour ce besoin ?)
• QUOI : Quel est ce besoin ?
• POURQUOI : Quelle est la valeur ajoutée si l’on répond à ce besoin ?
• OK, MAIS POURQUOI ? : Que risque-t-on si nous ne développons pas cette fonctionnalité ?

Rédiger de manière claire et précise ton user story (US)

• Tout commence par un titre : une bonne US commence avec un titre simple, explicite et exhaustif. C’est la première chose que l’équipe lira, il donne le ton et permet d’avoir rapidement une vision de la demande. Le reste ne sert qu’à détailler le titre. Ce titre sera aussi ton meilleur ami pour retrouver l’US au milieu d’un backlog bien rempli et la mentionner facilement en daily meeting, sprint planning et autres cérémonies.
• Suivi d'un énoncé en 3 lignes clés : tu les attendais, les voilà : « en tant que », « je veux », « afin de ». Si tu as suivi la check-list pour définir le périmètre de ton US, ces 3 lignes ne sont qu’un jeu d’enfant. N’oublie pas : l’US est une histoire courte. Reste simple, va à l’essentiel, et ne fait pas de ces 3 lignes un paragraphe à rallonge. Concentre-toi sur la valeur que ton utilisateur pourra en ressortir.
• Sans oublier le détail sous forme de scenarios : il est maintenant temps de s’adresser au reste de la squad et de donner quelques indications pour que les équipes techniques puissent réaliser leur travail sans s’éloigner de l’énoncé.

Sur ce point, il existe plusieurs manières de faire. Nous t’en proposons une qui te permettra de poursuivre sous la forme d’une histoire et de maintenir un langage commun pour toute l’équipe : le langage Gherking,  issu de la méthodologie BDD (Behaviour Driven Development). L’idée est simple : détailler la fonctionnalité en donnant des exemples concrets de cas d’utilisation, sous la forme de scénarios (4 maximum). Encore une fois : reste simple, clair et concis.

Les avantages d'utiliser le langage Gherking :  cette méthode permet de s’assurer que l’on a bien pensé à toutes les possibilités d’utilisation, et inclut les critères d'acceptance de manière à pouvoir automatiser les tests par la suite (les QA peuvent facilement reprendre les scénarios et les rentrer sous forme de code).

Au début, nous conseillons de consulter plusieurs personnes aux profils différents avant de rédiger ces scénarios - par exemple en organisant un atelier type les 3 Amigos - toujours pour aligner l’équipe sur la compréhension de la fonctionnalité. Au fil du temps, un langage commun s’installe et tu pourras rédiger des scénarios clairs seul.

• ‍En fonction du l'US des règles métiers peuvent s'appliquer : enfin, ta fonctionnalité devra entrer en conformité avec certaines contraintes dues au métier, secteur ou encore au produit en lui-même (exemples : accessible que par les utilisateurs à l'abonnement premium, l'utilisateur doit-être connecté à son compte, le mot de passe doit contenir au moins 8 caractères dont une minuscule, une majuscule, etc. ) ‍
• Une dernière chose ajoute des illustrations à ton l’histoire. Car finalement, une image peut valoir mille mots et restera le meilleur langage universel. N’hésite pas à intégrer des schémas ou maquettes pour illustrer ta user story, il n’y en aura jamais de trop.

Discuter de tes US pour s’aligner avec ton équipe

Ton US est bientôt prête ! Il ne te reste plus qu’à la présenter au reste de l’équipe lors du backlog refinement pour la discuter et si besoin la faire évoluer. Cette étape est souvent négligée, et elle est pourtant indispensable. Rappelle-toi le mantra n°2 : une US est faite pour aligner l’équipe en créant la discussion. Applique-toi donc à garder un moment pour discuter les US, quelle que soit la situation du produit.
Quelques conseils pour créer la discussion et en tirer le maximum :

• ‍Raconte l'histoire de l’US à ton équipe : plutôt que de lire l'énoncé en 3 phrases, part du besoin ou de la difficulté rencontrée et crée la conversation.
• ‍Autorise les remarques et les questions : il est normal que l'équipe te challenge, chacun apporte sa pierre à l'édifice ‍
• Sache dire non : tu restes le garant de la vision produit et de la voix utilisateur.

On peut facilement se perdre dans la rédaction d’une user story (US) si l’on recherche le modèle parfait qui respecte toutes les règles de l’art.
‍

Pour conclure, rappelle-toi toujours pourquoi tu les rédiges. Elle est l’item de travail qui doit permettre à ton équipe d’avancer dans le développement du produit. Intègre bien les 2 mantras (se concentrer sur la valeur aligner l’équipe) et suis les 3 étapes (délimiter le périmètre, rédiger, discuter). Grâce à ces conseils, ton US alliera qualité et pertinence. Le format idéal viendra avec la pratique ! Prochain défi : bien prioriser tes user stories dans le backlog produit.

‍

Ce qu'il faut retenir d'une bonne user story :

• Chaque US doit se concentrer sur la valeur utilisateur.
• Elle doit parler à toute l'équipe en utilisant un langage commun et accessible à tous et raconter une histoire.
• Chaque US doit vivre dans ton backlog et tu dois toutes les présenter à ton équipe.