Comment animer un workshop de Story Mapping avec l'IA

Avant de lancer le workshop, il faut cadrer le sujet. Quel problème essayons-nous de résoudre ? Quel est le périmètre ? Un workshop de story mapping efficace commence TOUJOURS par une question claire, pas par un backlog vide.

Invitez les bonnes personnes : le Product Owner, 2-3 développeurs, un UX designer, un expert métier. Gardez le groupe en dessous de 8 personnes — au-delà, les discussions deviennent improductives. Un facilitateur dédié (Scrum Master ou autre PM) est un vrai plus.

Préparez un document de contexte qui résume le problème, les utilisateurs cibles et les contraintes. Ce document sera importé dans mapiro pour alimenter le Knowledge Graph et permettre des générations contextualisées.

Le facilitateur démarre le workshop en exposant le problème à résoudre. Pas de backlog, pas de tickets — juste une question claire : « Nos 12 000 collaborateurs n'ont aucun accès self-service à leurs données RH. Comment digitaliser leur parcours ? »

Chaque participant doit comprendre POURQUOI on fait ce workshop et QUEL résultat on attend. Le cadrage doit inclure : le contexte métier, les utilisateurs impactés, et les contraintes connues (budget, délais, stack technique).

C'est le moment de s'aligner sur le vocabulaire : qu'est-ce qu'un Epic ? Une Feature ? Une User Story ? Si tout le monde n'est pas au même niveau, prenez 5 minutes pour clarifier.

Avant de mapper les stories, il faut savoir POUR QUI on construit. L'erreur classique est de créer un story map générique « pour tout le monde ». Résultat : un produit qui ne satisfait personne.

Identifiez 2 à 4 personas maximum. Pour chaque persona, définissez : qui ils sont, ce qu'ils cherchent à accomplir, et quelle est leur frustration principale. Priorisez un persona principal — c'est lui qui guidera le fil conducteur du story map.

Si le groupe est grand, utilisez un exercice de convergence : chaque participant écrit ses personas sur des post-its (2 min), puis on regroupe et vote pour sélectionner les 3 principaux.

Le backbone est la colonne vertébrale de votre story map. Il représente les grandes étapes du parcours utilisateur, vues du point de vue du persona principal. Ce sont vos Epics.

Pensez en termes de « grandes actions » que l'utilisateur réalise : « S'inscrire », « Consulter ses données », « Faire une demande », « Suivre l'avancement ». Chaque action devient un Epic.

Ordonnez les Epics de gauche à droite dans l'ordre chronologique du parcours utilisateur. Ce n'est pas l'ordre de développement — c'est l'ordre dans lequel l'utilisateur vit l'expérience.

N'incluez pas uniquement les Epics fonctionnels. Pensez aussi aux Epics techniques ou transverses nécessaires (authentification, conformité, intégrations) — ils sont souvent oubliés en workshop.

C'est le cœur du workshop. Pour chaque Epic, on descend d'un niveau pour identifier les Features (capacités), puis les User Stories (actions concrètes de l'utilisateur).

Utilisez le format standard : « En tant que [persona], je veux [action] afin de [bénéfice] ». Ce format force la discussion sur le POURQUOI, pas seulement le QUOI.

Ne cherchez pas la perfection. L'objectif du workshop est de capturer l'essentiel, pas de rédiger des spécifications détaillées. Les stories pourront être enrichies ensuite.

Encouragez le groupe à penser « parcours utilisateur complet » : si Sophie veut modifier son adresse, quelles étapes traverse-t-elle ? Se connecter → Accéder à son profil → Modifier → Confirmer → Recevoir une notification.

C'est le moment le plus stratégique du workshop. Vous avez un Story Map complet — maintenant, il faut tracer la ligne du MVP : quelles stories DOIVENT être dans la première livraison ?

Le piège classique : tout mettre dans le MVP. Le MVP n'est pas « le produit final en version light » — c'est la plus petite version qui délivre de la valeur à l'utilisateur et permet de valider une hypothèse.

Utilisez le test du « parcours complet » : le MVP doit permettre au persona principal de réaliser au moins UN parcours complet de bout en bout. Pas la moitié de 3 parcours.

Les stories qui ne sont pas dans le MVP doivent être réparties en releases : Release 2 (prochaine livraison), Release 3 (plus tard), ou Long Term Ideas (peut-être un jour).

Le MVP est défini — maintenant, il faut planifier son exécution. Combien de sprints faut-il ? Quelles stories dans quel sprint ? Dans quel ordre ?

Le sprint planning en workshop se fait à un niveau macro : on ne rentre pas dans l'estimation précise en story points (ça, c'est le travail du refinement d'équipe). On définit les grandes lignes : Sprint 1 = fondations, Sprint 2 = parcours principal, Sprint 3 = finitions.

Règle d'or : chaque sprint doit avancer un nombre limité d'Epics (2-3 max) pour éviter le context-switching. Et le Sprint 1 doit livrer quelque chose de démontrable — même petit.