Le Story Mapping, notre retour d’expérience

Qu’est-ce que le Story Mapping ? Comment prépare-t-on cet atelier ? Quel est son intérêt ? Cet article va vous apporter des réponses à ces questions au travers d’un retour d’expérience.

Qu’est ce que le Story Mapping ?

Le Story Mapping est un outil très utile pour la création de nouveaux produits. Il permet à la fois de décortiquer un besoin et de ranger les différentes fonctionnalités par thème et par priorité.

Au cours d’un atelier de Story Mapping, tous les participants (PO, scrum master, développeur, métier…) vont disposer des post-it représentant chacun une fonctionnalité, sur un tableau :

  1. L’axe horizontal du tableau est l’axe des thèmes, ou l’axe chronologique, suivant lequel sont décrites les différentes actions réalisées par l’utilisateur tout au long de son parcours.
  2. L’axe vertical du tableau représente la priorité : les fonctionnalités les plus importantes sont situées en haut de la Story Map et les moins importantes en bas. Une fois tous les post-it placés sur le tableau, on va alors tracer des traits qui vont symboliser les différents lots du produit.

Cet outil nous donne la priorité des différentes fonctionnalités ainsi qu’une première roadmap des différents releases. Évidemment, la Story Map peut être amenée à évoluer en fonction des différents retours client, comme un backlog.

storymapping

(source)

Le Story Mapping, comment ça marche ?

Après un atelier de Story Mapping, on a une idée bien précise de ce que contiendront les prochains sprints et les premières releases du produit. L’équipe pourrait presque déjà commencer le développement du produit. En outre, cet outil offre d’autres possibilités ; la représentation de la Story Map en tableau, par exemple, facilite la participation, contrairement à l’atelier « prune the product tree » qui a une représentation moins cartésienne.

Au cours d’un projet, nous avons utilisé ce format d’atelier pour revoir un des parcours utilisateur d’un produit existant. Le parcours utilisateur que nous voulions reprendre n’était pas centré sur le client et comportait nombreuses anomalies ; il était constitué d’un amas de fonctionnalités mal articulées entre elles. Cet atelier nous a donc permis de remettre à plat les besoins des utilisateurs, leur importance ainsi que la façon de les aborder. Voici comment s’est déroulé l’atelier et ce que nous avons pu observer.

Comment s’est déroulé l’atelier ?

Voici comment nous avons joué l’atelier :

Avant l’atelier de story mapping, nous avions défini plusieurs personas pour nous aider dans la définition des parcours client. Pour l’atelier qui a duré 2 heures, nous avions divisé le temps imparti en plusieurs périodes de divergence et convergence de la façon suivante :

Début de l’atelier de story mapping : 15 minutes de présentation
L’important dans la présentation de l’atelier est de bien rappeler les raisons qui ont poussé à la construction, ou reconstruction du produit. Quels étaient les points de douleur des clients s’il y en avait, les anomalies présentes et le coût de correction de ces anomalies. Nous avons aussi présenté ce qui était attendu à la fin de l’atelier et quel était notre objectif.

Première phase de divergence sur le sujet : 25 min réflexion
Les participants, organisés en groupes de 4, ont commencé à réfléchir sur les différents parcours client. Pour cela, ils sont partis d’un persona et ont imaginé le parcours effectué par le client ainsi que son besoin à chaque étape du parcours.

Identification des thèmes : 10 min de mise en commun et convergence
Pour cette étape, chaque groupe présente les différents besoins qu’il a identifiés tout au long du parcours. De là sont tirées les grandes étapes qui composent le parcours client.

Deuxième phase de divergence : 45 min réflexion
Comme lors de de la première phase de divergence, les participants travaillent en groupe pour compléter la Story Map en considérant tous les personas.

Restitution finale du story mapping : 25 min pour la mise en commun globale et isolation des sujets prioritaires
La priorisation des fonctionnalités les unes par rapport aux autres est faite avec tous les participants. Pour faire cette priorisation, nous avons à la fois comparé les fonctionnalités entre elles et priosé par rapport aux personas. La priorisation par les personas permet de mettre en avant les clients que nous voulons adresser en premier (une niche d’early adopters par exemple).

Finalement ça a donné quoi ?

Des points positifs …

L’ensemble des participants au Story Mapping a bien compris l’intérêt de l’atelier et surtout pourquoi nous voulions refaire le produit, chose pas toujours acquise en entreprise. L’atelier a permis de donner une bonne vision du produit à tous les participants. Dans des entreprises qui fonctionnent généralement en silo, cela permet d’embarquer tout le monde dès le début du projet.

Au cours de l’atelier, le fait de bien limiter en temps les phases de divergence et convergence a permis d’optimiser la concentration des participants.

La comparaison entre le produit existant et le produit idéal (vision obtenue) permet de bien mettre en avant les lacunes actuelles et les points d’attention à avoir. Les différents thèmes identifiés aident à clarifier le parcours client ainsi que les limites du produit.

… et quelques axes d’amélioration

Un premier point qui aurait pu être amélioré, aurait été d’inclure les personnes responsables du budget dans l’entreprise afin de partager avec eux la vision et les raisons de la construction du produit. En effet, ces personnes décident souvent de l’enveloppe budgétaire d’un projet suivant un brief sans avoir forcément la vision globale.

Un autre aspect que nous aurions pu revoir était la priorisation. Pour la dernière partie, nous avions pris le parti de faire une priorisation comme pour un Story Mapping classique ; on tire des traits horizontaux suivant les priorités. Dans notre cas de refonte d’un produit existant, il aurait fallu considérer autre chose pour la priorité comme les thèmes ou étapes du parcours délaissés dans la version actuelle du produit. Comme le nouveau produit sera surement en production en même temps que l’ancien, cela nous aurait permis de mieux prioriser les fonctionnalités à développer sans que le client ait l’impression de perdre des fonctionnalités. En effet, il est difficile pour un client de comprendre pourquoi il perd des fonctionnalités sur son nouveau produit. Ainsi, mettre en avant les améliorations du nouveau produit par rapport à l’ancien permet de garder le même périmètre fonctionnel et améliore l’expérience client.

Finalement cet atelier était pour nous un premier pas dans le projet pour embarquer le plus de personnes dès le début, il a servi d’atelier de vision. Nous avons pu identifier qui étaient les différents intervenants, chose pas forcément facile dans les grandes organisations, ainsi que mieux mettre en avant les besoins et contraintes client.

4 Comments Le Story Mapping, notre retour d’expérience

  1. Pingback: Roadmap - Le blog des Thiguys

  2. Pingback: Méthodes Agiles | Pearltrees

  3. BADREAU Stéphane

    Bon article, il est utile de préciser également que le Story Map va permettre l’initialisation du Backlog Produit.
    Dans le schéma de représentation de la Story Map, ci-dessus, les releases (versions du produit) sont définies en général suivant la ligne temporelle (horizontale) et non pas verticale… mais bon, cela n’engage que moi !

    Reply
  4. Pingback: Le top des ressources agiles de l’Oeil de Coach - Blog OeilDeCoach.com

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *