Si vous travaillez dans la gestion de produits depuis aussi longtemps que moi (15+ ans), vous avez certainement vu la transition des longs documents de spécifications produits (PRDs) décrivant les fonctionnalités vers les backlogs Agile décrivant des user stories.
Personne ne regrette les PRDs, n'est-ce pas ?
Les méthodes Agile sont indéniablement une amélioration, mais un backlog produit plat peut très vite devenir une liste non structurée et interminable d'éléments, difficile à maintenir.
Une façon d’avoir une vision d’ensemble est de créer une carte des user stories. Cela vous permet d’obtenir un aperçu de l’ensemble des fonctionnalités complexes d’un produit. C'est utile lors du lancement d’un nouveau produit, mais aussi pour ajouter de nouvelles fonctionnalités à un produit existant. La carte des user stories peut aussi vous aider à définir les épopées (epics) et user stories.
Qu’est-ce que le user story mapping ?
Le user story mapping est une méthode pour structurer un produit complexe en parcours utilisateurs. Elle a été décrite pour la première fois par Jeff Patton, qui a écrit un livre entier à ce sujet. Cela fait partie de la méthodologie Lean Startup.
La carte des user stories décrit l’expérience utilisateur de votre produit du point de vue de l'utilisateur. À ne pas confondre avec une carte du parcours client, qui décrit des parcours intégrant motivations, questions et émotions du client, mais qui n’est pas forcément centrée sur le produit lui-même.
Les 3 niveaux du user story mapping
Une carte des user stories comporte trois niveaux. Regardons chaque niveau avec un exemple d’un site internet d’hôtel.
Niveau 1 - Activités
Il s'agit des activités que les utilisateurs effectuent dans votre produit. À ce stade, vous pouvez rester à un niveau assez global ou plus détaillé, selon vos besoins. Je vous conseille de commencer par des activités assez globales afin que le niveau supérieur ne dépasse pas 10 éléments au départ. Les activités sont formulées comme des résultats que les utilisateurs souhaitent atteindre. Les activités sont disposées horizontalement sur la carte.
Pour notre site d’hôtel, à un niveau global, les principales activités pourraient être :

Niveau 2 - Étapes
Le niveau suivant correspond aux étapes que les utilisateurs suivent dans votre produit pour accomplir les activités décrites au niveau 1. Ces étapes sont également organisées horizontalement.
Dans l’exemple de notre site d’hôtel, les étapes pourraient être :

Niveau 3 - Détails
À ce niveau, vous décrivez en détail ce dont les utilisateurs ont besoin pour réaliser les étapes décrites au niveau 2. Ici, vous incluez toutes les données et interactions nécessaires pour compléter chaque étape.
Le niveau 3 est organisé verticalement sous les activités et les étapes. Pour poursuivre l’exemple de notre site d’hôtel, les détails pourraient être :

Comment construire une carte des user stories
Avant de commencer la création d’une carte des user stories, assurez-vous de bien connaître les problèmes exacts que votre produit résout, les types d’utilisateurs auxquels vous vous adressez, ainsi que les besoins de vos utilisateurs. Certaines personas UX peuvent vous être utiles.
Avant de vous engager dans la rédaction des user stories elles-mêmes, beaucoup d’équipes gagnent à esquisser d’abord la narration générale. Le storyboarding—qui s’inspire des techniques du cinéma et du design—permet aux équipes de visualiser le parcours émotionnel de l’utilisateur et le contexte avant de définir des interactions spécifiques. Si le user story mapping met en lumière le « quoi » et le « pourquoi » des fonctionnalités du produit, le storyboarding éclaire le « comment cela se ressent » et le « ce qui précède et suit » les moments clés d’interaction.
La cartographie des récits utilisateurs (user story mapping) est une tâche collaborative. Au minimum, vous aurez besoin des membres de votre équipe pluridisciplinaire de développement produit. Vous pouvez également inviter des membres du support client, du marketing, des équipes de vente, ou toute autre partie prenante ayant une bonne compréhension des attentes des utilisateurs envers votre produit. Cela garantit que vous disposez tous d’une compréhension partagée de votre produit dans son ensemble.
Cependant, il n’est pas nécessaire de construire une carte de récits utilisateurs en une seule session. Il est conseillé d’établir au moins une liste complète des activités de niveau 1 lors de la première séance afin que tous les membres de l’équipe puissent percevoir la complexité globale du produit et détecter rapidement les risques et dépendances. En revanche, tous les détails de niveaux 2 et 3 peuvent être développés ultérieurement, au moment de travailler sur l’activité de niveau 1 correspondante.
Lorsque vous choisissez de créer une carte de récits utilisateurs, vous avez plus de chances d'obtenir une vision globale et, par conséquent, de concevoir le bon produit.
Outils de cartographie des récits utilisateurs
Pour construire physiquement votre carte, tout support qui ne se détériore pas en quelques jours conviendra. Si vous travaillez en équipe co-localisée, vous pouvez utiliser un tableau blanc ou même un mur pour y coller des notes adhésives. C’est un excellent moyen de stimuler la créativité, mais l’inconvénient est que les notes tombent souvent au bout de quelques jours ! Si vous utilisez un mur, je recommande vivement d’en prendre des photos.
Bien sûr, une meilleure alternative consiste à opter pour une des nombreuses solutions collaboratives de tableaux blancs virtuels ou des logiciels de gestion de récits utilisateurs.
Cartographie des récits utilisateurs et développement Agile
Que vous utilisiez Scrum, Kanban ou une méthode hybride comme approche de développement logiciel Agile, vous devrez déterminer comment prioriser les fonctionnalités de votre produit. Une carte des récits utilisateurs permet de visualiser facilement l’ensemble du produit, les éléments à prioriser pour la prochaine version et ce qu’il reste à développer.
La cartographie de tout le produit présente également l’avantage de pouvoir le découper de plusieurs façons pour la priorisation de la feuille de route produit.
Vous pouvez découper la carte des récits utilisateurs verticalement lorsqu’il est possible d’isoler certains parcours clés pour la fonctionnalité d’un Produit Minimum Viable (MVP).
Dans l’exemple de notre site web d’hôtel, vous pouvez par exemple ne publier en ligne que les informations sur votre hôtel et les prix des chambres, sans gérer toute la réservation en ligne. Lors de votre toute première version, les clients pourront trouver toutes les informations nécessaires pour prendre une décision mais devront appeler ou envoyer un email pour réserver une chambre.

Vous pouvez aussi découper la carte des récits utilisateurs horizontalement pour offrir un parcours minimum de bout en bout à vos clients. Dans notre exemple d’hôtel, cela pourrait signifier mettre en ligne une recherche de chambre et un processus de réservation basique, sans y intégrer tous les services additionnels réservables.

Transformer une carte des récits utilisateurs en backlog Agile
Finalement, pour développer votre produit, il vous faudra probablement transformer votre carte de récits utilisateurs en un backlog Agile plat avec des récits utilisateurs pour la priorisation et la planification des sprints.
Peut-être vous demandez-vous si cela ne fait pas double emploi ? En réalité, les détails de niveau 3 de votre carte peuvent facilement être repris pour créer les récits utilisateurs et les critères d’acceptation de votre équipe Agile. Donc, bien qu’il y ait une légère redondance, rédiger les récits utilisateurs devient facile à partir d’une bonne carte de récits utilisateurs.
Pourquoi utiliser la cartographie des récits utilisateurs ?
En conclusion, il existe de nombreux avantages à privilégier la carte des récits utilisateurs face à un backlog Agile plat :
- Vous obtenez une vision globale de votre produit pour comprendre l’étendue du travail à réaliser.
- Vous pouvez identifier plus facilement et plus tôt les risques et dépendances.
- Vous pouvez prioriser plus aisément le travail de vos sprints Agile à partir d’une carte structurée plutôt qu’à partir d’un backlog plat et non structuré.
- Vous bénéficiez d’une compréhension partagée à l’échelle de l’entreprise des activités utilisateurs prises en charge par votre produit.
Si vous souhaitez en savoir plus sur les méthodes de gestion de produit les plus efficaces, abonnez-vous à notre newsletter.
Article connexe : Qu’est-ce qu’une Epic Agile ? Bonnes pratiques, modèle & exemple
Vous agrandissez votre équipe ? Voici quelque chose d'utile : Comment créer une fiche de poste efficace pour un Product Manager Agile (+Exemple)
Aussi à découvrir :
