Ecrire des User Stories efficaces

Aujourd’hui on revoit une des bases et des tâches les plus récurrentes du rôle de Product Owner qui est d’écrire des tickets ou “user stories” (ou US).

“Facile! déjà vu!” hurleront les plus expérimentés. Cependant cette tâche étant répétitive, chronophage, voire ingrate, elle subit parfois quelques raccourcis au détriment de leur bonne compréhension par les développeurs et les autres membres de l’équipe présente ou future.

Avez vous déjà perdu du temps, pour comprendre le (dys)fonctionnement de votre produit, à tenter de décrypter le ticket sans contexte ni précisions d’un prédécesseur trop pressé ?

Don’t be that PM.

La minute définition

Pourquoi “user story” ?

Parce qu’il s’agit de la description d’une fonctionnalité du point de vue de ses utilisateurs, ce qui permet de dresser les contours du résultat attendu le plus fidèlement possible.

La user story s’écrit typiquement sous le format appelé Gherkin :

“En tant que” / “Etant donné que” (qui je suis en tant qu’utilisateur)

Exemple : en tant que client sur la page d’un article de mon site e-commerce

“Lorsque” (action réalisée)

Exemple : Lorsque je clique sur le bouton “acheter”

“Alors” (résultat)

Exemple : Alors l’article est ajouté à mon panier

Au delà de cette description, on veut donner à nos développeurs toutes les informations et précisions nécessaires à la réalisation de la tâche, c’est pourquoi au delà de cette formulation “user story” désigne aussi par extension les tickets créés par les product owners à l’attention des développeurs.

Ceux-ci doivent permettre une bonne compréhension du sujet par la personne qui réalisera la tâche, mais aussi par ceux qui les consulteront dans le futur, pour comprendre l’historique et la conception d’une fonctionnalité par exemple.

De bonnes user stories permettent donc plus d’efficacité dans la delivery en évitant les incompréhensions, et un meilleur partage de connaissances produit/tech sur le long terme.

S’il existe des méthodes pour évaluer l’efficacité d’une user story (notamment la méthode INVEST) cela peut s’avérer assez théorique pour cette tâche quotidienne qu’est la rédaction d’US.

L’idéal est de se créer une trame, un template efficace et réutilisable.

Nous avons donc interrogé plusieurs PO et PM sur leurs meilleures pratiques pour écrire des US précises et concrètes.

Voilà sans plus attendre leurs conseils pour créer votre propre modèle.

Un titre court et synthétique

“Le titre des US doit être parlant, synthétique et pragmatique. La partie, un peu verbeuse ETQU... je souhaite... afin de... , je la garde pour la description du ticket.”

Un titre court permet de comprendre rapidement le contenu d’un ticket, mais aussi de faciliter sa recherche par des personnes en quête de compréhension du produit. Le titre est l’élément le plus important pour retrouver un ticket spécifique.

On aura généralement dans le ticket des étiquettes, Epics et autres tags facilitant le filtrage, mais le fait de mettre le tag principal dans le titre permet une visualisation en un clin d’oeil.

Cela peut être par exemple :

• une typologie : [URGENT], [TRANSVERSE], [BUG], etc…
• un périmètre : [programme de fid], [booking funnel] etc…

Le choix du tag à ajouter à votre titre dépendra de ce qui est le plus pertinent pour votre produit, votre secteur d’activité, l’organisation de la squad ou encore la synchronisation entre équipes.

A vous d’en décider avec les personnes concernées.

Du contexte

“J’essaye en préambule de mettre un maximum de contexte pour que les devs puissent comprendre le sujet plus global. Le ticket est souvent rattaché à une epic qui décrit précisément le WHY et les KPIs de succès, mais je re-précise toujours le contexte dans le ticket.”

On démarre le ticket en donnant du contexte avant même la description de ce que l’on veut faire.

Cela permet non seulement d’engager davantage l’équipe technique dans la cohérence globale du produit, mais aussi de s’assurer que l’on est bien au clair sur le besoin auquel on répond, ce que l’on cherche à impacter et comment le mesurer.

Pour participer à cette contextualisation, on peut ajouter de la data, des liens, des captures d’écrans, ou tout élément utile à la compréhension du sujet.

Je rajoute (parfois) un lien vers un thread Slack. Ce thread apporte souvent du contexte, des explications techniques qui ne sont parfois pas liées directement au tickets mais qui vont être utile à sa compréhension.

Je rajoute (si besoin) un rappel simplifié, au format texte, de la roadmap. L’idée c’est de préciser, si nécessaire, quand est-ce que le ticket sera recetté ou mise en prod.

Du visuel

Après avoir posé le contexte on va décrire ce que l’on souhaite faire, et dans cette partie, rien de tel que du visuel que ce soit un schéma, une maquette voire un prototype.

Je rajoute souvent un screenshot des maquettes en plus du lien direct vers le Figma dans la story.

On veut qu’un ticket soit complet et compréhensible mais aussi facilement lisible. Pour qu’aucun élément ne soit oublié lors de la lecture trop rapide d’un ticket, ce qui peut arriver aux meilleurs d’entre nous, le visuel donne du corps et du rythme.

Un truc tout bête, j’ai un template avec de la couleur et une hiérarchie des infos hyper claire, ca aide les dévs à s’orienter tout de suite vers les infos dont iels ont besoin.

Les critères d’acceptance

C’est là qu’intervient le fameux format Gherkin

“En tant que” / “Etant donné que”

“Lorsque”

“Alors”

Une fonctionnalité peut avoir un ou plusieurs critères d’acceptance, lorsque ceux ci sont assez nombreux une présentation sous forme de tableau peut être plus lisible :

Le fait de lister les critères d’acceptance va permettre non seulement d’être très clair sur ce qu’il faut faire et les différents cas à traiter, mais va aussi faciliter les tests.

La rédaction de mes critères d’acceptance dans mes tickets a elle même un rôle, elle guide ma pensée du macro (contexte) vers le micro. C’est souvent au moment de ce changement d’échelle que j’identifie des edge cases et que j’apporte encore plus de précisions.

Ces critères d’acceptance peuvent être l’occasion de revoir le découpage d’une fonctionnalité en plusieurs US, lors d’un tres amigos par exemple.

Avant mes backlog refinements j’organise un tres amigos pour revoir mes US avec le/la lead dev, le/la QA et éventuellement d’autres devs selon le sujet en question et leurs compétences spécifiques. Ca me permet de valider que mes US et leur contexte sont claires et compréhensibles, et de valider les critères d’acceptance.

Lorsque l’on n’a pas la chance d’avoir une personne dédiée à la QA dans l’équipe, ChatGPT peut être assez pertinent sur la rédactions des critères d’acceptance.

Il faudra évidemment lui donner du contexte (attention, pas d’infos sensibles), les réponses sont à relire, à adapter et a corriger si nécessaire bien évidemment mais elles peuvent être un gain de temps non négligeable et apporter certains cas d’usages auquel vous n’aviez pas pensé.

Les précisions techniques

A ce stade, le ticket doit être déjà suffisamment précis pour être présentés à vos développeurs et leur permettre d’échanger sur la solution technique à adopter lors d’un grooming, backlog refinement, ou quelle que soit l’appellation de vos cérémonies.

Notre dernier conseil est d’ajouter les précisions techniques au ticket, car la personne qui le réalisera aura pu oublier des détails entre temps où simplement ne pas être présente ce jour là.

Cela participe aussi à la documentation et permet aussi de garder l’historique de la solution choisie pour le futur, sans avoir besoin de remettre les mains dans le code.

Lors des refinements, nous échangeons sur l’US et nous assignons un développeur pour qu’il écrive les guidelines techniques pour le prochain poker planning, car sans cela le chiffrage est plus approximatif et cela permet de commencer à réfléchir à la solution technique adaptée.

A nouveau, tout conseil est à adapter à son contexte et c’est maintenant à vous de trouver le format qui fonctionne pour votre organisation.

Un grand merci à Barnabé, Géraud et Nicolas de nous avoir partagé leurs conseils en rédactions d’US. Nous espérons que vous aurez pu trouver ici quelques bonnes idées à intégrer dans vos tickets!