La User Story Map est une cartographie du produit permettant de générer des User Stories et de les associer à des activités “métier” pouvant être améliorées dans le cadre du nouveau produit.

Une fois identifié les User Stories qui amélioreront l’expérience des utilisateurs, le mapping permet de les prioriser et de former des versions en cohérence avec un objectif métier clair.

Quand faire un story mapping

Le Story Mapping est à initier lors du cadrage du projet (au moment de réfléchir aux services que nous souhaitons apporter aux utilisateurs), il peut aussi être initié lors de la préparation d’une nouvelle version.

Le story mapping est aussi un outil de pilotage tout au long du projet permettant de mesurer ce qui a été fait et de faire émerger de nouveaux services de manière agile.
Lorsque les équipes auront commencé à construire le produit, vous pourrez l’utiliser pour matérialiser les nouveautés à venir, les services déjà rendus (pour plus de détails, rendez-vous dans le chapitre “Durée de vie du Story Mapping”)

• Les clients et utilisateurs : cela permet de bien comprendre à qui s’adresse le futur produit, qui sont les usagers, qui sont les payeurs pour mieux appréhender leurs besoins respectifs et savoir y répondre
• La vision produit : qui permet de comprendre les enjeux derrière le produit, quels problèmes ou limitations il adresse
• La vision business : les objectifs pour l’entreprise, n’imaginons pas qu’un produit ou un service crée de la valeur uniquement pour les utilisateurs et utilisatrices. Il crée forcément de la valeur pour l’entreprise et il est fondamental de se dire laquelle pour comprendre certaines demandes qui finalement servent plus l’entreprise que les utilisateurs. N’oublions pas, nous avons des clients à l’intérieur de l’entreprise qui ont leur propres enjeux.
• Les objectifs métier et les critères de réussite : qu’essayons nous d’atteindre au travers du produit et comment mesurer que nous avons réussi. Poser les objectifs métiers et critères de réussite nous permettent d’éviter de nous focaliser sur la quantité de livrable pour mieux viser des impacts métier et business

L’objectif, à ce stade est de comprendre et fédérer autour de ce que nous souhaitons atteindre, notre ambition pour l’entreprise et les utilisateurs.
Le story mapping n’a surtout pas vocation à classer une liste d’idées fonctionnelles exhaustives. Il cherche à maintenir une certaine sobriété en se focalisant sur la génération de fonctions répondant à une vision, à des objectifs clairs et pour des utilisateurs définis.

Prévoir un premier atelier d’introduction de 2h permettant de rappeler aux participants la vision, les objectifs, les personas et tout autre élément structurant permet aux participants d’appréhender le contexte.

Ensuite, le nombre d’ateliers va dépendre de la durée globale de construction du produit.
Pour un petit produit qui n’a qu’une seule version à livrer en 3 mois, deux à trois ateliers répartis sur une semaine ou deux devrait suffire.
Pour un produit de grande envergure prévu sur plusieurs versions à livrer en plusieurs étapes, prévoir des ateliers tout au long du cadrage qui permettront d’affiner la roadmap notamment pour la première version. Prévoyez à minima un atelier Story Map de 2h toutes les semaines.

Participants

• Le lead MOA ou le Product Owner du projet. La personne en charge d’animer les parties prenantes, de prioriser et de construire la roadmap
• Les parties prenantes, entités, utilisateurs finaux, sponsors présentes pour exprimer les besoins et les prioriser. Leur rôle sera de faire remonter les attentes au Product Owner ou le lead MOA qui a le mandat pour faire la priorisation finale
• Des représentants MOE utile pour fournir quelques indications sur le contexte technique, les freins à la mise en œuvre de certain sujets

Pour animer cet atelier, il est nécessaire d’avoir la capacité de prendre du recul, d’être dans l’animation du collectif.
Le cas contraire, le risque est de s’enfermer dans des débats sans fin et de passer à côté de la construction de la cartographie.

La structure de base d’une Story Map est un tableau contenant :

• En colonnes des activités (en bleu dans le schéma fig. 1)
• Pour chaque activité, identifier les services ou fonctions du nouveau service permettant d’activer, de servir ou améliorer l’expérience de l’activité (en jaune dans le schéma fig. 1)
• Sur la gauche du tableau, les versions en ligne (en rose dans le schéma fig. 1) et les objectifs recherchés pour chaque version. Une bonne pratique consiste à limiter au maximum les objectifs par version et d’identifier les indicateurs qui permettront de vérifier que l’objectif a été atteint (en fushia dans le schéma fig. 1)

Une bonne pratique consiste à décrire l’activité à partir d’un verbe d’action à l’infinitif “Accéder”, “Gérer”, “Piloter”…
Une autre bonne pratique consiste aussi, si possible, à remplir les activités dans un ordre logique, chronologique afin de raconter l’histoire du métier des utilisateurs.

Si vous avez plusieurs utilisateurs, partez de l’utilisateur principal, décrivez ses activités puis pour les autres usagers, identifiez les activités communes et ajoutez les activités spécifiques.

Il est intéressant de chercher à identifier, les besoins, les services à rendre, les fonctions recherchées.
Exemple : si vous deviez décrire une cafetière, préférez “pouvoir réchauffer le café déjà fait” plutôt que “avoir un bouton pour allumer la plaque chauffante”.

Si votre produit devait répondre à 1 objectif, lequel serait-il ? Et comment mesureriez-vous que vous l’avez atteint ?

Cette stratégie a pour but, encore une fois, de tirer le produit par son impact plus que par la liste de ses fonctionnalités.

Et donc de déprioriser les fonctions qui répondent à des objectifs futurs.

L’autre possibilité consiste à utiliser la méthodologie MoSCoW et former vos versions en fonction. Néanmoins, cette méthode ne vous protège pas de tout vouloir, tout mettre en MUST ou de former des versions trop chargées (même en mettant des quotas sur le MoSCoW).

Il n’est pas nécessaire de tenter de faire une priorisation exhaustive sur toute la durée de vie du produit. Essayez de prioriser la version à venir et potentiellement la suivante. Prioriser les suivante n’aura aucun intérêt dans un projet agile puisque de nouvelles fonctions vont émerger, les priorités peuvent changer etc.

La Story Map est un outil vivant qui évolue dans le temps au gré de l’avancement, des décisions, des possibilités et reflète la réalité du projet.

Vous pouvez maintenir des ateliers de mise à jour avec les parties prenantes pour les futures version ou communiquer l’avancement global. Vous pouvez animer des rendez-vous réguliers avec l’équipe de développement pour l’informer des sujets à venir ou des décisions métier.

De fait la cartographie a la durée de vie du projet associé tout simplement.

• C’est un outil 2 en 1 visuel qui permet d’avoir rapidement une vision globale et temporelle d’un produit tout en offrant une vision plus détaillées des fonctions pour celles et ceux qui en ont besoin
• Il permet de réunir toutes les parties d’un projet pour construire et suivre les sujets
• Il permet de créer des produits focalisés sur l’usage et les utilisateurs sans oublier le business
• Il permet de se focaliser sur l’intérêt des fonctionnalités plus que les fonctionnalités elles-mêmes
• Sa mécanique facilite grandement les réflexions pour bien prioriser
• C’est un outil vivant qui évolue au gré du projet

Essayez le story mapping pour un nouveau projet, pour une future version mais ATTENTION ! Initiez le au bon moment ! Pas juste au moment de développer mais bien pour cadrer, structurer l’avenir et ENSUITE utilisez le pour suivre l’avancement et matérialiser l’évolution du produit