Le guide étape par étape pour animer un atelier de Story Mapping
Vous voulez cadrer efficacement un sujet ? Vous souhaitez vous lancer dans des ateliers de Story Mapping avec votre Métier, pour maturer une problématique, une Epopée. Des membres de la Communauté de Pratiques de la Famille Produit d’AXA France (regroupant des Product Manager, Product Owner, Business Analyst) ont conçu ce modèle Draft.io pour vous.
A partir d’un exemple concret, ce template vous guidera, étape par étape pour que votre Story Mapping soit un succès !
Mais avant, un peu d’histoire
Le Story Mapping est une pratique créée par Jeff Patton (auteur du livre “Le Story Mapping”), dont l’idée forte est de raconter des histoires (d’où la notion de “Story”) de manière collaborative avec des mots et des images pour créer une compréhension mutuelle. Les stories sont des discussions sur la résolution de problèmes pour l’entreprise, les clients, les utilisateurs.
Cet atelier est principalement utilisé pour la maturation et le cadrage de “gros” sujets de type Epopées (ou Epic en anglais).
Le Story Mapping favorise :
- La discussion et la création collective d’un produit,
- La vision d’ensemble de solutions en définissant des objectifs partagés,
- Une priorisation avec la notion de MVP et de stratégie incrémentale,
- La remontée au plus tôt des risques et des incertitudes par toute l’équipe.
Qui participe à cet atelier ?
- Un facilitateur : Product Manager, Product Owner ou Business Analyst,
- Le ou les Métiers,
- L’équipe de Réalisation (développeur et testeur).
Afin que l’atelier soit efficace, il est essentiel d’avoir uniquement :
- Les personnes qui savent poser les bonnes questions,
- Les personnes qui savent répondre aux questions.
“Si la personne chargée de développer un logiciel pouvait simplement parler avec quelqu’un qui a compris les besoins des utilisateurs du logiciel et leurs motivations, on trouverait alors souvent des moyens plus rentables de contenter les utilisateurs.” — Jeff Patton.
A quel moment lancer le Story Mapping ?
Dès que le sujet a été priorisé par votre Métier, vous pourrez vous lancer dans les ateliers, mais pas de n’importe quelle façon. En fonction de sa complexité, vous aurez 2 outils à votre disposition :
- Pour maturer un sujet complexe : le Story Mapping est efficace pour dégrossir un sujet et l’affiner en fonctionnalités (Minimum Marketable Feature ou MMF),
- Pour maturer un sujet ciblé (une évolution d’un bout de parcours, par exemple), privilégiez l’Event Storming/Modeling. Mais, ceci fait l’objet d’un autre article.
Le Story Mapping, en 9 étapes
Un travail avec des cartes
Il n’existe pas réellement de normes de cartes ou de couleurs dans un Story Mapping, contrairement à un Event Storming/Modeling. Aussi nous vous proposons ceci :
Dans le Story Mapping de Jeff Patton, 4 cartes sont essentielles :
- Le thème qui regroupe un ensemble d’activités,
- L’activité que l’on peut considérer comme une Feature,
- La fonctionnalité que l’on va développer (qui, selon sa taille peut être une userstory, une MMF ou même un ensemble de MMF),
- La question pour conserver une trace des questions posées pendant l’atelier et pour y répondre par la suite.
Nous y avons ajouté d’autres cartes :
- L’objectif qui est une part essentielle du Story Mapping, à savoir : définir la priorisation des fonctionnalités du produit par versions (Ceci fera l’objet d’un prochain article sur les OKR).
- La fonctionnalité livrée : il s’agit d’une fonctionnalité existante en Production. Intéressant quand on souhaite différencier l’existant d’une nouveauté,
- La dépendance technique que les équipes peuvent remonter dès le Story mapping (pour la gestion des risques).
Etape 0 : Préparation Elevator Pitch : La vision du produit
Il s’agit de la phase préparatoire de l’atelier. Avec votre Métier, préparez le speech que vous allez présenter aux participants. Comme son nom l’indique, cette intervention doit être courte et aller à l’essentiel de la problématique à résoudre?
Etape 1 : Elevator Pitch & brainstorm sur les activité
C’est le jour J. Devant les participants, le Métier présente son Elevator Pitch. Auparavant, vous demanderez à toutes les personnes présentes d’écrire, de son côté, chaque activité qu’il a pu entendre lors de la présentation.
Etape 2 : Définir la chronologie des activités
Les activités écrites par les différents participants seront partagées et placées collectivement sur une échelle de temps, en plaçant l’activité qui démarre et les suivantes jusqu’à celle qui finalise le sujet ou parcours.
Etape 3 : Définir les thèmes regroupant les activités
Suite aux différentes discussions et — vous le découvrirez — de façon naturelle, les participants regrouperont différentes activités cohérentes entre elles au sein d’une carte “thème”. Cette carte n’a pas obligation d’exister. Il s’agit surtout d’aider les participants à structurer les activités.
Remarque : Il peut même arriver qu’il n’y ait pas de thème, ou qu’une activité soit aussi un thème.
Etape 4 : Affecter le/les Persona
C’est à ce moment que l’on positionne le ou les personae qui sera/seront impliqué(s) sur chaque activité, dans l’échelle de temps.
Etape 5 : Définir les fonctionnalités par activité
A cette étape, les participants devront décrire collectivement l’ensemble des fonctionnalités qui seront à développer pour chaque activité.
Remarque : il est important d’indiquer aux intervenants de ne pas se limiter dans leurs réflexions car, par les interactions des questions ou de nouvelles idées pourront survenir et pourraient répondre à la problématique.
Etape 6 : Définir les objectifs de versions et les indicateurs de réussite (ou OKR : Objectives and Key Results)
Il s’agit de définir avec le Métier la priorisation des fonctionnalités à développer, en indiquant :
- L’Objectif pour répondre à la question « Où allons nous ? »
Il fixe la cible d’une organisation, d’une équipe ou d’une personne,
Ils doivent être ambitieux et qui inspire,
Cela permet de réfléchir ensemble aux questions : “Pourquoi nous lançons cette cadence ?”, “Cela va-t-il apporter un impact positif sur notre produit ?”.
- Le résultats clé répond à la question « Comment allons-nous réussir ? »
Il matérialise les conditions de succès de l’objectif,
Ce sont des indicateurs mesurables (KPI)
On peut mesurer les résultats clés en utilisant une échelle de 0 à 100%. Par exemple 40% des prospects ont été relancés ou 70% du projet a été accompli,
On peut utiliser un indicateur numérique tel que le chiffre d’affaire généré, le taux de conversion ou encore le NPS pour mesurer la satisfaction client,
Si le résultat clé n’est pas mesurable, on indiquera un 0 pour non accompli et un 1 pour accompli.
Pour en savoir plus : Les OKR ou comment définir des objectifs clairs et mesurables pour vos versions | by Silvere Duval | Just-Tech-IT | Jun, 2022 | Medium
Etape 7 : Affecter les fonctionnalités aux objectifs
Pour répondre aux objectifs et donc aux priorisations, les intervenants déplaceront les différentes fonctionnalités par objectif. Il s’agira de la première forme d’engagement sur ce qui devra être développé.
Etape 7bis : Maturer les fonctionnalités prioritaires avec l’Event Storming/Modeling
A ce moment, les fonctionnalités de l’objectif prioritaire seront maturées lors d’un Event Storming/Modeling. Mais cet atelier ne fait pas partie du Story Mapping.
Pour en savoir plus : Story machin, Event truc, Example chose, je m’y perds ! | by Silvere Duval | Medium
Etape 8 : Représenter la progression des développements
Le Story Mapping vit tout du long du produit. C’est un excellent outil de communication visuelle pour indiquer l’avancée des travaux.
Etape 9 : Consulter régulièrement le Story Mapping et le mettre à jour en fonction des nouvelles priorisations
Le Story Mapping pouvant devenir une documentation vivante, il est possible de représenter la dépriorisation ou la repriorisation de fonctionnalités.
Vous utilisez une Backlog à 3 niveaux ?
Voici une proposition de correspondance entre le Story Mapping et les backlog Epopée, Minimum Marketable Feature (MMF) et Stories (Userstories, Technical Stories et bugs).
Pour terminer, quelques conseils
- Pour une réunion efficace, faites participer votre Métier pour éviter de perdre du temps en imaginant ce qu’ils pourraient penser ou en leur posant des questions après réunion,
- Démarrez par un sujet simple pour monter en compétence sur cet atelier,
- N’abusez pas du “Mapping”, sinon vous allez perdre du temps. Cartographiez uniquement ce qui vous suffit pour rédiger votre parcours,
Vous souhaitez mettre à jour un parcours déjà existant ? Vous pouvez partir juste avant l’endroit où vous allez ajouter une nouveauté et vous arrêter juste après là où elle se termine.
- Ne vous perdez pas dans les détails, vous aurez tout le temps de le faire lorsque vous maturerez les fonctionnalités prioritaires (via l’Event Storming/Modeling, par exemple),
- Ne faites pas référence à vos outils mais misez sur les fonctionnalités à apporter, sinon, votre esprit perdra de la créativité en réfléchissant sur ce que l’outil actuel est capable de faire,
- Présentez régulièrement votre Story Mapping à votre équipe et votre Métier pour ne pas oublier les objectifs de la version en cours, pour garder la vision d’ensemble ou en y faisant référence lors de vos montées en production,
- Faites vivre votre Story Mapping, même après l’atelier pour montrer la progression des développements, des changements d’orientations,
“Dans un processus de logiciel traditionnel, la pratique du “ré-examiner et supprimer” serait synonyme de mauvaise spécification, mais quand vous avez votre casquette de développeur agile, il s’agit simplement d’apprentissage et d’amélioration itérative.” — Jeff Patton.
- Partagez, débriefez avec d’autres équipes sur le Story Mapping pour monter en compétence.
Un dernier conseil
Utilisez les OKR qui aideront et guideront votre équipe tout au long des développement, en répondant au “Finalement, pourquoi je développe cette fonctionnalité ?”, question qui arrive régulièrement après des semaines de développements.
Merci
Merci à Evelyne Ly, Tiago Marques et Hélène Perez pour la co-création de ce template.
Sources de cet article
“Le story mapping — Visualisez vos user stories pour développer le bon produit” — Jeff Patton.
“Measure what matters” — John Doerr
Pour aller plus loin
Pour lire la version anglaise de l’article
The step-by-step guide to running a User Story Mapping workshop — Blog (draft.io)
