Guide d’animation de l’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 ont conçu ce modèle Draft.io pour vous.

A partir d’un exemple, 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, dans le but de construire une compréhension mutuelle d’une situation donnée. Les stories sont des discussions sur la résolution de problèmes pour l’entreprise, les clients ou les utilisateurs. Cet atelier est principalement utilisé pour mûrir et cadrer des “gros” sujets de type Epopée (ou Epic en anglais).

Le Story Mapping favorise :

• La discussion et la création collective d’un produit ;
• La vision d’ensemble de solutions à travers la définition d’objectifs partagés ;
• La priorisation avec la notion de MVP et la mise en oeuvre d’une stratégie incrémentale ;
• L’identification et la qualification des risques et des incertitudes par toute l’équipe, en amont du projet.

Qui participe à cet atelier ?

Participent généralement à 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 de réunir 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.

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 fera l’objet d’un prochain article.

Le Story Mapping, en 9 étapes

Un travail avec des cartes

Contrairement à l’Event Storming/Modeling, dans un Story Mapping, il n’existe pas réellement de norme en ce qui concerne les cartes ou les couleurs à utiliser. C’est pourquoi nous vous proposons celle-ci :

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 assimiler à une Feature ;
• La fonctionnalité que l’on va développer (qui, selon sa taille, peut être une user story, une MMF – Minimum Viable Feature – ou même un ensemble de MMFs) ;
• 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, et qui va déterminer l’ordre dans lequel seront implémentées les fonctionnalités (ceci fera l’objet d’un prochain article sur les OKR) ;
• La fonctionnalité livrée : il s’agit d’une fonctionnalité qui existe d’ores et déjà en Production. Intéressant quand on souhaite différencier le périmètre existant du périmètre en cours de conception ;
• La dépendance technique que les équipes peuvent identifier dès le Story mapping (pour la gestion des risques).

Etape 0 : Préparation de l’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 & brainstorming sur les activités

C’est le jour J. Devant les participants, le Métier présente son Elevator Pitch. Auparavant, vous demanderez à chacune des personnes présentes d’écrire, de son côté, l’ensemble des activités qu’elle a pu entendre lors de la présentation.

Etape 2 : Définir la chronologie des activités

Les activités écrites par chacun des participants seront partagées et placées collectivement sur une échelle de temps, en positionnant les activités dans l’ordre chronologique du processus décrit.

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 les activités qui partagent une caractéristique commune au sein d’une carte “thème”. Cette carte n’est pas obligatoire, mais peut 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 là 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, des questions et des interactions entre les participants, peuvent naître des idées innovantes qui pourraient répondre à la problématique posée.

Etape 6 : Définir les objectifs de versions et les indicateurs de réussite (ou Objectives and Key Results)

En collaboration avec le Métier, il s’agit de définir l’ordre dans lequel les fonctionnalités doivent être implémentées, 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. Il doit être ambitieux et inspirant. Il 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é, qui répond à la question « Comment allons-nous réussir ? »

Il matérialise les conditions de succès de l’objectif. Il est associé à un indicateur mesurable (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’affaires généré, le taux de conversion ou encore le NPS qui mesure la satisfaction client. Si le résultat clé n’est pas mesurable, on indiquera un 0 pour non accompli et un 1 pour accompli.

Etape 7 : Affecter les fonctionnalités aux objectifs

Pour répondre aux objectifs et donc aux contraintes de priorisation, 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 Modeling

Au cours de cette étape, les fonctionnalités de l’objectif prioritaire seront maturées grâce à un Event Storming/Modeling. Mais cet atelier ne fait pas partie du Story Mapping.

Etape 8 : Représenter la progression des développements

Le Story Mapping vit en paralèlle du cycle de vie du produit. C’est un excellent outil de communication visuelle pour présenter l’avancée des travaux.

Etape 9 : Consulter régulièrement le Story Mapping et le mettre à jour en fonction des nouvelles priorités

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, MMF et Stories (User stories, Technical Stories et bugs).

Pour terminer, quelques conseils

Ci-dessous, quelques conseils pour faire de cet atelier une réussite :

• 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 étant contraint de leur poser des questions après la réunion ;
• Démarrez par un sujet simple pour monter en compétence sur cet atelier ;

Remarque : 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êtez 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 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é, car vous vous focaliserez 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 et garder la vision d’ensemble, ou faites-y 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 et des changements d’orientations ;

“Dans un processus de développement logiciel traditionnel, la pratique consistant à “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 et 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éveloppements, en répondant au “Finalement, pourquoi je développe cette fonctionnalité ?”, question qui survient régulièrement après des mois de développement.

Remerciements

Merci à Evelyn Ly, Tiago Marques et Hélène Perez pour la co-création de ce template.

Ressources

“Le story mapping — Visualisez vos user stories pour développer le bon produit : Visualisez vos user stories pour développer le bon produit” — Jeff Patton.
“Measure what matters” — John Doerr.