Comment animer un atelier storymap

En bref

Résumé

3h pour tronçonner un sujet en petits éléments actionnables et les prioriser en équipe grâce au management visuel.

Objectif

Avoir une vue d’ensemble du sujet à cadrer, rangé par catégories (activités) et priorisé en Must Have / Should Have / Nice to Have, pour alimenter directement le backlog produit.

Pourquoi faire une storymap ?

Un backlog classique est une liste verticale de user stories. Le problème : il est impossible de visualiser le parcours complet de l’utilisateur en le lisant. On voit des morceaux, jamais le tableau d’ensemble.

C’est exactement ce constat qui a poussé Jeff Patton à formaliser la storymap dans son ouvrage User Story Mapping (O’Reilly, 2014). Sa réponse : disposer les éléments sur deux axes :

• L’axe horizontal représente le parcours chronologique de l’utilisateur (de gauche à droite)
• L’axe vertical représente la priorité (de haut en bas, du plus important au moins important)

Ce double axe permet à toute l’équipe de voir d’un coup d’oeil ce que fait l’utilisateur, dans quel ordre, et ce qui est prioritaire. C’est un outil de communication avant d’être un outil de planification.

Définition : Une storymap est une représentation visuelle du parcours utilisateur, découpé en activités (grandes étapes) et en tâches (actions détaillées), organisées chronologiquement et priorisées verticalement.

Matériel nécessaire

Préparez tout avant l’arrivée des participants. Rien de pire qu’un atelier qui démarre par 10 minutes de recherche de feutres.

En présentiel :

• Post-it de 2 couleurs différentes : une pour les activités, une pour les tâches (1 bloc par personne, soit environ 6 à 10 blocs au total)
• Feutres épais (1 par personne) : les feutres fins sont illisibles à distance
• Un grand mur vide ou un panneau de liège (minimum 3 mètres de large)
• Du ruban adhésif de masquage (pour tracer les lignes de priorisation)
• Un paper-board pour les attentes et les questions
• Un appareil photo ou un téléphone pour documenter le résultat final
• Une horloge visible ou un timer projeté

En distanciel (Miro / FigJam) :

• Un board Miro ou FigJam préparé avec les zones délimitées
• Un template avec l’axe horizontal et les 3 zones de priorité pré-tracées
• Un code couleur identique pour activités et tâches (utilisez les couleurs de post-it virtuels)
• Un lien de visioconférence avec les caméras allumées

Composition du groupe

L’atelier fonctionne idéalement avec 5 à 8 personnes. Au-delà de 8, les discussions deviennent trop longues et la priorisation tourne au débat sans fin.

Profils nécessaires :

• Le responsable produit ou projet : c’est la personne qui tranchera lors de la priorisation. Sa présence est indispensable.
• Les membres de l’équipe technique : développeurs, designers. Ils apportent la réalité de la faisabilité et pensent aux cas limites.
• Un ou deux représentants métier : ils connaissent les besoins utilisateurs et les contraintes business.
• L’animateur : il facilite, recadre et gère le temps. Il ne participe pas au contenu.

Si vous ne pouvez pas avoir le responsable produit, reportez l’atelier. La priorisation sans décideur est un exercice vide.

Programme (3h)

Phase 1 : Explication de l’atelier (15 min)

Montrer la vidéo

Commencez par projeter cette courte vidéo qui explique le concept de storymapping :

Pour cet atelier, les “steps” de la vidéo seront appelées activités et les “user stories” seront appelées tâches.

Rappeler les objectifs

Formulez l’objectif clairement : “À la fin de ces 3 heures, nous aurons une vue d’ensemble du parcours utilisateur, découpé en activités et en tâches, et priorisé en Must Have / Should Have / Nice to Have.”

Distribuer le matériel

Donnez à chaque participant un bloc de post-it (couleur “tâches”) et un feutre épais. Gardez les post-it de couleur “activités” pour l’exercice collectif qui suit.

Recueillir les attentes

Faites un tour de table rapide : “Qu’attendez-vous de cet atelier ?” Notez les réponses sur le paper-board et laissez-le visible pendant toute la séance. Cela permet de vérifier en fin d’atelier que les attentes ont été couvertes.

Phase 2 : Écriture des activités (15 min)

Les activités sont les grandes étapes du parcours utilisateur. Elles décrivent ce que l’utilisateur fait à un niveau macro.

Comment identifier une activité

Une activité répond à la question : “Que fait l’utilisateur à ce stade de son parcours ?” Elle commence toujours par un verbe à l’infinitif et tient sur un seul post-it.

Exemples de bonnes activités :

• “Découvrir l’offre”
• “Créer son compte”
• “Passer commande”
• “Suivre sa livraison”

Exemples de mauvaises activités (trop vagues ou trop précises) :

• “Utiliser le site” (trop vague, c’est l’ensemble du parcours)
• “Cliquer sur le bouton Ajouter au panier” (trop précis, c’est une tâche)

Le déroulement

L’écriture des activités se fait en collectif. L’animateur mène la discussion, l’équipe propose les activités, et on les dispose par ordre chronologique sur une première ligne horizontale, de gauche à droite.

Visez entre 5 et 10 activités. En dessous de 5, votre parcours est probablement trop simplifié. Au-dessus de 10, vous êtes probablement trop granulaire.

Exemple pour un site de club sportif :

• Trouver une date de match
• Acheter mes billets
• Récupérer mes billets
• Assister au match
• Partager mon expérience

Phase 3 : Écriture des tâches (1h15)

C’est la phase la plus longue et la plus riche de l’atelier. Les tâches sont les actions détaillées contenues dans chaque activité.

Comment formuler une tâche

Une tâche répond à la question : “Concrètement, que fait l’utilisateur pour accomplir cette activité ?” Elle commence aussi par un verbe à l’infinitif et tient sur un seul post-it. Écrivez gros, en 3 à 5 mots maximum.

Règle importante : chaque tâche doit décrire une action de l’utilisateur, pas une fonctionnalité technique. “Filtrer les dates par mois” est une bonne tâche. “Implémenter un composant de filtre” n’en est pas une.

Le déroulement

Contrairement aux activités, l’écriture des tâches se fait en individuel puis en collectif :

1. Phase individuelle (20 min) : chaque participant écrit silencieusement les tâches qu’il imagine, une par post-it.
2. Phase collective (55 min) : chacun vient coller ses post-it sous l’activité concernée, en expliquant brièvement. L’équipe regroupe les doublons, discute les divergences, et complète les manques.

Si une tâche ne rentre dans aucune activité existante, c’est qu’il manque une activité. Ajoutez-la. Si une activité n’a aucune tâche, elle est peut-être superflue. Supprimez-la. La storymap est un document vivant qui s’ajuste pendant l’atelier.

Exemple détaillé pour un site de club sportif :

Activité : Trouver une date de match

• Consulter le calendrier des matchs
• Filtrer par équipe
• Sélectionner une date
• Lire les infos complémentaires (lieu, heure, adversaire)

Activité : Acheter mes billets

• Choisir ma catégorie de place
• Sélectionner le nombre de billets
• Mettre au panier mes achats
• Voir mon panier
• Valider mon panier
• Entrer mes informations de paiement
• Voir la confirmation de paiement

Activité : Récupérer mes billets

• Voir mon billet sur le site après l’achat
• Retrouver mon billet dans mon espace personnel
• Réceptionner mon billet par email
• Ajouter le match à mon agenda

Phase 4 : Pause (15 min)

Ne sous-estimez jamais l’importance de la pause. Après 1h30 de travail intense, le cerveau a besoin de décrocher. Profitez-en pour prendre une photo de la storymap en cours : si des post-it tombent pendant la pause, vous pourrez les replacer.

Phase 5 : Parcours et relecture (15 min)

Une fois la pause terminée, l’équipe prend du recul et relit l’ensemble de la storymap.

Le test du parcours

Demandez à un membre de l’équipe de “raconter l’histoire” en suivant les activités et les tâches de gauche à droite, de haut en bas. Les autres écoutent et réagissent :

• Est-ce que le parcours fait sens chronologiquement ?
• Y a-t-il des trous (des moments où l’utilisateur ne sait pas quoi faire) ?
• Y a-t-il des parcours alternatifs oubliés (erreurs, cas limites, premier utilisateur vs utilisateur récurrent) ?

Les parcours alternatifs

Pensez aux cas suivants :

• L’utilisateur qui arrive pour la première fois vs celui qui revient
• L’utilisateur qui rencontre une erreur (paiement refusé, page introuvable)
• L’utilisateur sur mobile vs sur desktop
• L’administrateur vs l’utilisateur final

Ajoutez les tâches manquantes. N’hésitez pas à créer de nouvelles activités si nécessaire.

Phase 6 : Priorisation (45 min)

C’est la phase la plus stratégique. Elle transforme une carte visuelle en plan d’action.

La méthode MoSCoW

La priorisation se fait selon la méthode MoSCoW, formalisée par Dai Clegg en 1994 :

• Must Have (indispensable) : sans ces tâches, le produit ne fonctionne pas. C’est le strict minimum viable.
• Should Have (important) : le produit fonctionne sans, mais l’expérience est dégradée. C’est la cible de la V1.
• Nice to Have (souhaitable) : ce serait bien de l’avoir, mais ce n’est pas critique. C’est la V2 et au-delà.

Il existe parfois un 4e niveau, Won’t Have (exclu pour le moment), mais en pratique les 3 premiers suffisent.

Comment tracer les lignes

À gauche de votre storymap, tracez 2 lignes horizontales avec du ruban adhésif. Ces lignes divisent l’espace vertical en 3 zones :

• Zone du haut : Must Have
• Zone du milieu : Should Have
• Zone du bas : Nice to Have

Le déroulement de la priorisation

Procédez colonne par colonne (activité par activité) :

1. L’animateur lit les tâches d’une activité
2. L’équipe discute de la priorité de chaque tâche
3. Le responsable produit tranche en cas de désaccord
4. Les post-it sont déplacés verticalement dans la bonne zone

Attention : la priorisation est relative, pas absolue. Une tâche est “Must Have” par rapport aux autres tâches de la même activité. L’objectif est de réduire le scope de la première version, pas de tout classer en Must Have.

Le piège du “tout est prioritaire”

Si tout est Must Have, rien n’est prioritaire. En règle générale, visez cette répartition :

• Must Have : 30 à 40 % des tâches
• Should Have : 30 à 40 % des tâches
• Nice to Have : 20 à 30 % des tâches

Si votre zone Must Have contient plus de 50 % des tâches, challengez chaque élément : “Si on ne le fait pas pour la V1, est-ce que le produit est inutilisable ?” Si la réponse est non, descendez-le en Should Have.

Les erreurs fréquentes

Après avoir animé des dizaines de storymaps, voici les erreurs que je vois revenir le plus souvent.

Être trop granulaire

Certaines équipes descendent au niveau du champ de formulaire : “Saisir son nom”, “Saisir son prénom”, “Saisir son email”. C’est trop fin. À ce stade, une seule tâche “Remplir le formulaire d’inscription” suffit. Le détail viendra dans les user stories lors du développement.

Être trop vague

L’inverse est tout aussi problématique. “Gérer son compte” n’est pas une tâche, c’est une activité. Si un post-it peut être découpé en 5 sous-éléments, c’est probablement une activité déguisée en tâche.

Oublier les cas limites

Les parcours principaux sont faciles à identifier. Ce sont les parcours d’erreur, les cas limites et les parcours secondaires qui sont souvent oubliés. Posez systématiquement la question : “Et si quelque chose se passe mal à cette étape ?”

Prioriser trop vite

Certaines équipes veulent prioriser chaque tâche au moment où elles l’écrivent. Résistez. La priorisation se fait à la fin, quand la vue d’ensemble est complète. Prioriser trop tôt biaise le jugement car on n’a pas encore la vision globale.

Ne pas impliquer les développeurs

La storymap n’est pas un exercice réservé au product owner et aux designers. Les développeurs apportent une vision technique indispensable : ils pensent aux cas limites, aux contraintes d’intégration, aux dépendances techniques. Leur présence enrichit considérablement la qualité de la storymap.

Adapter l’atelier au distanciel

Les outils

Miro et FigJam sont les deux outils les plus adaptés. Créez un board avec :

• Une ligne horizontale pour les activités
• Un espace large en dessous pour les tâches
• 2 lignes de priorisation pré-tracées
• Un code couleur clair (jaune pour les activités, bleu pour les tâches, par exemple)

Les ajustements

• Réduisez la durée : 2h30 au lieu de 3h. L’attention en visio est plus courte.
• Utilisez un timer visible sur le board Miro
• Demandez les caméras allumées : c’est indispensable pour lire les réactions
• Utilisez le vote par points (dot voting) pour la priorisation : chaque participant dispose de 10 points à répartir sur les tâches qu’il juge prioritaires. Cela accélère considérablement la discussion.
• Faites des pauses plus fréquentes : une pause de 5 min toutes les 45 min

Le piège du distanciel

Le plus grand risque en distanciel est le désengagement silencieux. En présentiel, vous voyez qui décroche. En visio, quelqu’un peut couper sa caméra et faire autre chose. Pour contrer cela, interpellez régulièrement les participants par leur prénom et demandez-leur de réagir.

Que faire après la storymap ?

La storymap est un livrable intermédiaire, pas une fin en soi.

1. Photographiez ou exportez la storymap (en présentiel, prenez plusieurs photos sous différents angles)
2. Numérisez les tâches Must Have dans votre outil de backlog (Jira, Linear, Notion…)
3. Lancez le prototypage : les designers peuvent créer les premières maquettes en se basant uniquement sur les tâches Must Have. C’est le lien naturel avec un design sprint.
4. Affichez la storymap dans l’espace de travail de l’équipe (ou gardez le board Miro accessible) pour qu’elle serve de référence tout au long du projet

Exemple avant / après

Avant la storymap : un backlog plat de 47 user stories, sans ordre, sans priorité, sans vision d’ensemble. L’équipe ne sait pas par quoi commencer. Le product owner a une idée en tête mais elle n’est partagée par personne.

Après la storymap : 7 activités, 52 tâches organisées chronologiquement, priorisées en 3 niveaux. L’équipe voit le parcours complet. La V1 est clairement identifiée (18 tâches Must Have). Les développeurs savent ce qui vient en premier. Les designers savent quels écrans maquetter. Le product owner a validé les priorités devant tout le monde.

La différence n’est pas dans la quantité d’information. C’est dans la lisibilité et le consensus.

Pour aller plus loin

• L’atelier d’idéation : l’atelier qui précède souvent la storymap pour générer des idées
• Le design sprint : un cadre de 5 jours qui peut intégrer la storymap
• L’experience map : pour cartographier l’expérience utilisateur dans son ensemble
• L’atelier Mission / Vision : pour cadrer le projet avant la storymap

Sources

• Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly, 2014
• Dai Clegg, méthode MoSCoW, 1994 (formalisée dans le cadre DSDM)