Comment rédiger une bonne user story ?
Back to basics
La semaine dernière, j’ai challengé avec nos Lead Tech les 3 équipes produits que j’accompagne sur la structure de nos user stories que nous utilisons depuis déjà 3 ans !
J’en ressors 3 sujets intéressants à vous partager : comment bien différencier le contexte du besoin, mesurer l’impact de sa fonctionnalité et hiérarchiser ses tickets ?
💡 Vous trouverez à la fin de cet article le template type que nous utilisons
Bien définir le contexte et le besoin
Vous avez travaillé des semaines sur la phase de discovery d’une nouvelle fonctionnalité, vous avez décidé de la meilleure solution possible et c’est enfin le moment de lancer les développements. Décrire le contexte et le besoin peut donc à ce stade vous paraître superficiel. Pourtant, rappelez-vous que l’ensemble de l’équipe n’a pas forcément eu la chance de participer à toute la définition du besoin ! Ce sont donc deux éléments essentiels qui vous demanderont d’être à la fois clair et concis.
Le contexte est la situation ou le problème que l’utilisateur rencontre. Il répond à la question : “Quelle est la situation actuelle qui nécessite une solution ?”.
Le besoin, quant à lui, est ce que souhaite l’utilisateur pour résoudre ce problème. Il répond à la question : “Que veut l’utilisateur ?”
Par exemple, considérons que vous êtes Product Manager pour une application de remise en forme sportive. Votre équipe a pour objectif d’améliorer le taux de rétention et vous travaillez sur une fonctionnalité dédiée à la recherche.
Le contexte pourrait être “L’utilisateur vient de s’inscrire, il n’a pas fait de sport depuis longtemps.”
Le besoin serait : “L’utilisateur veut pouvoir trouver en quelques clics une séance dont le niveau et la durée sont adaptés à son niveau.”
En identifiant clairement le contexte et le besoin, vous pouvez formuler une user story concise et orientée vers la résolution du problème de l’utilisateur.
💡 Je recommande d’écrire le besoin ainsi :
Je suis un utilisateur,
Et lorsque j’arrive sur mon application de sport
Ce qui compte le plus pour moi c’est de pouvoir trouver en quelques clics une séance dont le niveau et la durée sont adaptés.
Mais il s’avère que tous les contenus sont mélangés et je n’arrive pas à trouver celui qui correspond le mieux.
A ce stade, aucune de ces deux parties ne parlent de la solution technique que vous allez mettre en place.
Ainsi, le besoin n’est pas “L’utilisateur veut avoir un module de recherche avec des filtres” !
Définissez clairement le succès de vos user stories
Le risque lorsqu’on enchaîne les développements, est de livrer des fonctionnalités sans s’assurer de leur impact. Avant de développer quoique ce soit, réfléchissez donc à des critères de succès clairs et mesurables. Ils peuvent prendre différentes formes, comme des indicateurs de performance, des critères de satisfaction utilisateur ou des résultats attendus.
Sur le même exemple que précédemment, une mesure du succès pourrait être : Augmentation de 10% du taux d’utilisateurs qui terminent une première séance tout de suite après l’inscription.
La mesure du succès permet de s’assurer que la fonctionnalité développée répond non seulement aux besoins des utilisateurs mais également à l’objectif business ou stratégique auquel vous participez, comme par exemple ici, augmenter le taux de rétention.
Rappelez-vous que cette mesure du succès permet également aux développeurs de se projeter sur l’impact de son développement sur les utilisateurs, ce qui est bien plus motivant que de juste répondre à un besoin.
Enfin, en identifiant bien la mesure du succès, vous vous apercevrez que vous n’avez pas encore mis en place un tracking permettant cette mesure. Une action technique sera peut-être nécessaire pour ajouter un événement Google ou Amplitude ou vous aurez peut-être besoin d’aide pour vérifier votre requête dans vos dashboards data (Metabase ou autre). Plus tôt vous collectez la donnée comportementale de vos utilisateurs, mieux c’est ! Il sera sinon difficile de pouvoir évaluer l’impact de votre fonctionnalité.
Mesurez l’impact de vos user stories
Il est important de distinguer une fonctionnalité terminée d’une fonctionnalité réussie. Une fonctionnalité terminée est une tâche technique achevée par les développeurs, tandis qu’une fonctionnalité réussie est une fonctionnalité qui a été mise en production, utilisée par les utilisateurs et qui a atteint ses mesures de succès prédéfinies.
Mais comment être certain de suivre cette mesure une fois le ticket développé ? Vous pouvez commencer par différencier ces deux statuts distincts dans votre outil de ticketing (Linear, Jira, etc.) et créer un board ou vous pouvez facilement distinguer les deux.
Personnellement, je suis les fonctionnalités de l’idéation jusqu’au succès dans un autre outil (Product Board) et Jira nous sert uniquement à suivre le développement.
💡 Partagez régulièrement vos succès ! En plus de quelques partage régulier sur Slack on organise une réunion une fois par trimestre avec l’ensemble de l’équipe pour présenter nos réalisations et leurs impacts. Un moment idéal pour célébrer nos succès !
Gardez un backlog bien structuré
Enfin, un dernier point purement pratique, réfléchissez en amont à bien hiérarchiser vos fonctionnalités.
Vous aurez plus ou moins de flexibilité en fonction de l’outil que vous utilisez. Jira propose par exemple 3 type de contenus : les épics, les user stories et les tâches.
Les épics : De plus haut niveau, les epics permettent de définir un objectif stratégique ou business, et/ou une macro fonctionnalité qui regroupe plusieurs user stories.
Attention à ne pas faire une epic trop large tel que “Création de compte” qui ressemble plus à une catégorie. En clarifiant l’objectif de votre epic, vous maitriserez davantage sa taille.User Story : Elle comporte un besoin bien spécifique et indépendant avec une mesure du succès bien identifié. Chaque user story apporte un bénéfice utilisateur indépendant qui peut participer à un objectif de plus haut niveau défini dans une epic.
Tâches et sous tâche : Je recommande de laisser ces deux niveaux aux développeurs qui, grâce à une user story bien décrite, pourront détailler la mise en oeuvre technique.
Conclusion
Dans l’agenda bien rempli d’un Product Manager, il peut être tentant d’écrire des tickets à la va-vite qui ne contiennent que la solution technique.
A ce stade, votre priorité n’est peut-être que d’alimenter les sprints de développement qui peuvent être assez intenses. Pourtant, en travaillant davantage ces différentes pistes cela vous permettra :
d’avoir une vision claire et synthétique du résultat de votre phase de discovery
de garder en tête ce pour quoi vous travaillez sur cette fonctionnalité
et surtout, le communiquer clairement à toute l’équipe qui n’en sera que plus motivée !
💡 Ce ne sont que quelques pistes qui nous ont permis d’améliorer la structure de nos user stories que je vous partage ci-dessous.
Template
Titre : simple, court, sans acronyme ou jargon technique.
Contenu :
Contexte
Décrire la situation actuelle dans laquelle s’inscrit cette fonctionnalité. Comment l’utilisateur est arrivé jusqu’ici ? Quelles sont ses caractéristiques ?
Besoin
Je suis [persona]
et lorsque je [contexte]
ce qui compte le plus pour moi c’est [besoin]
mais il s’avère que [contrainte]
et je dois donc [contournement]
Mesure du succès
Quels sont les indicateurs qui sont impactés par cette fonctionnalité ?
Risques
Quels sont les risques et points d’attention ?
Solution
Description de la solution et maquettes design qui vont permettre de faire le découpage technique en tâche et sous-tâche
Critères d’acceptances
Quels sont les critères d’acceptances établis avec votre QA ? Jeux de données, impacts sur le plan de testing actuel ?
En tant que … Lorsque … Alors …