User Story Mapping par Jeff Patton

User Story Mapping est une solution participative permettant de cartographier visuellement votre prochain produit numérique. C’est également une manière de définir votre roadmap produit et de préparer efficacement le backlog du projet agile. C’est une solution intégrée, intuitive et performante qui demande en contrepartie de l’organisation et beaucoup de dialogues.

User Story Mapping place les utilisateurs et leurs besoins au centre du projet en favorisant la conversation et la compréhension entre les parties prenantes afin d’aboutir in fine à un meilleur produit, répondant précisément aux besoins et apportant des solutions pertinentes et génératrices de valeur.

1. Préparation d’un User Story Mapping

Procurez-vous des Post-it en quantité et réservez un grand mur, situé de préférence dans votre espace projet afin d’interagir avec au quotidien.

ASTUCE : L’espace étant rare de nos jours et les déménagements fréquents, j’ai imaginé une solution permettant de déplacer le mur de Post-it sans avoir la fastidieuse, pénible et rébarbative tâche de tout décoller et de tout replacer au bon endroit : Procurez-vous une bâche de protection 3M Scotchblue (ou une bâche équivalente prévue pour protéger les murs) et fixez-la avec sa bande adhésive intégrée. L’électricité statique va plaquer le film sur le mur et vous pourrez ainsi coller vos post-it en toute liberté. Rq : vous pourrez également dessiner sur la bâche avec des marqueurs pour délimiter des zones.

Si votre équipe est en télétravail, je vous conseille l’un des tableaux digitaux suivant :

Miro. A partir de 8$/personne/mois. Miro possède une offre gratuite qui permet de tester la solution ou de partager une session en lecture seule avec un utilisateur éditeur.
Mural. A partir de 12$/personne/mois.
FigJam. Intégré à la très performante solution Figma, FigJam permet gratuitement de créer 3 tableaux.

Enfin, si vous avez établi votre User Story Mapping sur un mur physique mais que vous souhaitez partager le résultat en ligne, je vous recommande l’application Post-it. Cette application identifie chaque Post-it, reconnait l’écriture manuscrite et fait des exports dans Miro, Trello, Excel…

2. Validation du problème à résoudre

En amont de la solution, commencez par définir précisément le problème à résoudre auprès de vos utilisateurs en utilisant des boucles Lean Startup de type Build/Mesure/Learn ou Sense & Respond. Réalisez des prototypes, testez, apprenez afin de sélectionner la solution qui vous semble la plus adaptée.

3. Définition du contexte

A partir de cette étape, conviez toute l’équipe projet autour de votre mur. Créez une conversation informelle et discutez du contexte projet en notant chaque élément sur des post-it.

Points à aborder :

Objectifs du produit. Ces objectifs doivent répondre aux questions : Pourquoi faisons-nous cela ? Quelle est l’idée principale ? Que souhaitons-nous vraiment résoudre ? Pourquoi souhaitons-nous construire ce produit ? Il est important de se focaliser sur les résultats, pas sur les fonctionnalités attendues. Les bénéfices attendus doivent concerner à la fois les utilisateurs ET le business.
Profil des utilisateurs et des clients. Identifiez-les le plus précisément possible. Décrivez de quelles manières ils devraient utiliser le produit.
Idées et principes du produit. Indiquez les idées et les grandes lignes directrices que doit suivre le projet. Notez toutes les nouvelles idées émises par les participants et évaluez ensemble la pertinence et la faisabilité de toutes celles-ci par rapport aux objectifs.
Maquettes graphiques. Présentez-les dans leur état courant afin d’illustrer les concepts, les flux, différentes propositions en cours de test, mises à jour attendues…

4. Définition du plan d’ensemble

Concentrez-vous sur les activités principales du produit en se projetant dans le futur lorsque tout sera disponible :

Décrivez les activités principales sur des post-it placés chronologiquement de gauche à droite (narrative flow).
Associez le ou les utilisateurs concernés juste au-dessus de chaque activité. S’il s’agit de l’utilisateur Système, faites pivoter le Post-it à 45° pour bien le distinguer.
Précisez les étapes de chaque activité.
Détailler en colonne les détails de chaque étape.

5. Raffinage

Raffinez en équipe les activités, les étapes et les détails. Vérifiez la pertinence du découpage avec d’autres types d’utilisateurs. Améliorez les éléments avec toutes les parties prenantes.

Pour chaque étape, posez-vous les questions suivantes et enrichissez/modifiez le cas échéant :

Quelles sont les actions spécifiques que l’on fait ici ?
Quelles sont les actions alternatives que l’on pourrait faire ici ?
Comment pourrait-on réaliser cette action de manière vraiment cool ?
Qu’est ce qui peut mal se passer ?

6. Release Roadmap

Décomposez votre plan d’ensemble et faites apparaître les releases que vous estimez viables. Découpez en plusieurs lots (avec du ruban de masquage pour faire de belles lignes horizontales si vous travaillez avec des Post-it papiers) en indiquant pour chacun d’entre eux les résultats attendus (Outcomes, à gauche du tableau). Faites par exemple apparaître la solution minimale viable (MVP). Ou construisez un Functional Walking Skeleton du type « See it work », « Make it better », « Make it releasable », « This would make it even better but there may not be time ».

Build to learn:

Cherchez à construire pour apprendre, pas pour livrer directement une solution parfaite.
Produisant en petits lots, il est possible de recommencer une étape quand on se rend compte que les résultats attendus ne sont pas satisfaisants.
Construisez de manière itérative, en cherchant à chaque itération à produire quelque chose de fonctionnel et qui vous permettra d’apprendre également de vos utilisateurs.

7. Learning strategy

Identifiez les risques fonctionnels les plus importants et isolez-les dans de petits MVP. Lancez ces MVP rapidement afin de vous assurer que les fonctions concernées apportent réellement de la valeur au projet.

8. Development strategy

Identifiez les risques techniques et isolez-les dans de petits MVP. Planifiez rapidement la réalisation de ces MVP par vos développeurs pour vous assurer de la faisabilité de la solution.

9. Construction du Product Backlog et du Sprint Backlog

L’un des avantages du User Story Mapping est son appropriation très rapide par l’équipe de développement. Les détails de chaque étape d’une activité peuvent s’utiliser en tant que user stories et être ainsi injectés dans le Product Backlog puis dans le Sprint Backlog après raffinage et découpage en tâches élémentaires.

La solution pourra ensuite être enrichi tout au long du cycle de vie du projet en faisant apparaître les releases, les activités importantes, les points critiques, les nouveaux besoins, les fonctionnalités essentielles, etc.

Au-delà de la méthode

Dans son ouvrage, Jeff Paton va bien au-delà de l’application de sa méthode en expliquant avec de nombreux exemples, conseils pratiques et autres schémas comment construire de meilleures user stories. Ainsi il encourage à sortir de la structure souvent trop rigoureuse « En tant que… Je veux… Afin de… » en préconisant l’utilisation de cartes moins structurées du type « Who/What/Why » pour ouvrir les discussions tout en nous rappelant que « The Card is just the beginning ». Les stories présentées sous forme de carte ne sont qu’un support et ne doivent constituer qu’un point d’ancrage permettant de développer des conversations entre les membres de l’équipe. Le projet doit s’ancrer sur une démarche « Story driven communication » en se basant sur la communication entre les personnes, à l’opposé d’une démarche du type « Document driven communication », basée sur la transmission de user stories entièrement décrites par écrit et sans feedback entre les acteurs du projet.