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).

Jeff Patton

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.

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

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.