Le story mapping par Laure et Laurent

Qu’est ce que le Story Mapping ?

Le Story Mapping est une technique utilisée sur les projets agiles permettant de définir, de manière macroscopique, les besoins utilisateur d’un produit.

Ce type d’atelier a pour objectif d’obtenir rapidement la vision globale d’une nouvelle application à développer.

A la fin du processus une première version du Product Backlog sera définie et les releases du produit seront planifiées.

Le Story Mapping consiste à représenter les activités de l’utilisateur (succession chronologique des usages) sur un axe horizontal et de matérialiser les priorités fonctionnelles sur l’axe vertical (en haut celles qui sont indispensables, en bas les moins prioritaires). Le résultat obtenu est une organisation en deux dimensions des User Stories du Backlog produit. Le story mapping peut être un exercice complexe et peut prendre plusieurs jours à réaliser. Il doit être organisé avant le processus de développement.

Préparation

La manière la plus simple d’organiser un story mapping est d’utiliser un grand mur vide et des post-it de couleurs différentes.

Les ateliers de mapping peuvent inclure des représentants des utilisateurs, des spécialistes d’interface utilisateurs, des développeurs, des spécialistes du métier, … et bien évidemment le Product Owner ainsi que le Scrum Master.

Le choix des acteurs du Story Mapping est très important; il faut réunir les personnes qui possèdent la vision produit ainsi que toutes personnes faisant partie de l’équipe Scrum.

Le nombre de participants doit tout de même être limité afin que l’atelier puisse être constructif et que des décisions soient prises.

LE STORY MAPPING EN 7 ÉTAPES

1ère étape : Rechercher les “personas”

Dans un premier temps, il faut identifier les utilisateurs du produit (personas).

Cette approche permet de développer le bon produit et les bonnes fonctionnalités qui auront de la valeur pour les utilisateurs. Il faut toujours garder en tête qu’une fonctionnalité est développée pour un utilisateur ou un groupe d’utilisateurs et que chaque utilisateur n’utilise pas le système de la même manière. Le “système” peut également être un utilisateur (traitement batch, envoi de mails, ..).

Chacun des utilisateurs ou groupe d’utilisateurs doit alors être inscrit sur un post-it et disposé sur un axe horizontal.

2ème étape : Rechercher les usages de l’application

Lorsque les utilisateurs sont identifiés, il faut alors identifier leurs usages.

Pour y parvenir, il faut se poser la question “comment l’utilisateur va-t-il utiliser l’application ? ”.

L’idée est donc de lister les actions que l’utilisateur va réaliser sur le produit et ainsi dénombrer les fonctionnalités dont il aura besoin. Chaque tâche est répertoriée et placée sur un post-it (d’une autre couleur) sous l’utilisateur ou le groupe d’utilisateurs concerné. La bonne approche est de suivre l’objectif de l’utilisateur pour une activité dans le système et de noter chaque étape. Une étape correspond à une tâche.

Lorsque ce travail est fini pour l’ensemble des utilisateurs, il faut penser à vérifier les doublons car des utilisateurs différents peuvent réaliser la même tâche. Il n’est pas toujours simple de trouver le bon niveau de granularité d’une tâche ; attention de ne pas lister des épics ou des sous tâches. “Ajouter un utilisateur” est une tâche, “administrer la gestion des utilisateurs” est une épic, “saisir le nom de l’utilisateur” est une sous tâche.

3ème étape : Organiser les tâches en respectant le processus métier

Lorsque l’ensemble des tâches est répertorié, il faut ensuite les organiser selon l’ordre chronologique du processus métier en les plaçant horizontalement de gauche à droite. Cette organisation des tâches est réalisée pour chaque utilisateur ou groupe d’utilisateurs. Cette étape permet d’identifier les scénarii pour chaque utilisateur et de vérifier qu’il ne manque pas une tâche dans l’un des processus métier.

4ème étape : Rechercher des scénarii alternatifs

L’étape précédente permet souvent de déterminer le scénario principale d’un utilisateur par rapport au système.

Lors de cette étape il faut rechercher les scénarii alternatifs et ajouter les tâches en conséquence (envisager d’autres façons d’accéder à une fonctionnalité ou d’utiliser le produit, penser à la gestion des cas d’erreur, ….).

5ème étape : Regrouper les tâches en activité

Lorsque les tâches pour tous les scénarii sont identifiées, il faut les regrouper en “activité”.

Une activité regroupe l'ensemble des tâches qui correspondent à un même objectif. Toutes les tâches se rattachant à une même activité sont alors placées en colonne sous l’activité. Les activités seront ajoutées au Story Mapping avec des posts-it d’une autre couleur.

Les activités ainsi créées doivent former un workflow que l’utilisateur doit suivre pour réaliser un processus métier. Les activités doivent correspondre aux épics du Backlog Produit.

Par exemple l’activité “administrer la gestion des utilisateurs” devrait contenir les tâches “ajouter un utilisateur”, “supprimer un utilisateur”, “modifier un utilisateur”, “associer un utilisateur à une entreprise“, ...

A ce stade, il faudra faire attention à la granularité des tâches. Il apparaît parfois qu’une tâche est en fait une épic qu’il faudra à nouveau décomposer en tâches.

 
6ème étape : Déterminer les releases du produit

A cette étape nous avons :

• La liste des utilisateurs ou des groupes d’utilisateurs
• La liste des activités pour chaque utilisateur
• La liste des tâches pour chaque activité

Le story mapping devrait ressembler à ceci :

La liste des activités représente la liste des épics du Backlog et les tâches sont les User Stories à développer.

Il faut maintenant regrouper les tâches en releases. Pour cela on place des post-it sur le côté du Story Mapping avec le nom des releases (idéalement 2 releases suffises, il est surtout important de déterminer le contenu de la première release).

En face de chaque post-it de release on place les tâches qui la composeront.

Il faut alors déterminer les tâches les plus prioritaires apportant le plus de valeur au produit. Il se peut que certains utilisateurs soient écartés ou que certaines activités ne soient pas choisies pour la première release.

7ème étape : Valider avec les utilisateurs

Pour terminer le Story Mapping il est recommandé de vérifier la complétude des activités et des tâches avec les représentants de chaque type d’utilisateur et de valider le contenu de la première release. S’il manque des activités ou des tâches il suffit de les ajouter et d’ajuster le contenu des releases.

Résultats attendus

Les éléments du Story Mapping vont donner une vision du produit à développer.

Chaque release apportera des nouvelles fonctionnalités pour obtenir le résultat final attendu.

Le résultat du story mapping sera un support pour conserver la vision globale du projet tout au long des releases. Il conviendra de le faire évoluer en même temps que la vision produit (changement de priorisation, évolution des besoins utilisateur, ajout de nouvelles fonctionnalités, …).

D’autre part, les tâches identifiées lors du Story Mapping sont maintenant des User Stories indépendantes, priorisées et regroupées par épics. Le Backlog de produit est alors initialisé.

Enfin, il ne faut pas oublier que le story mapping est une technique et qu’un autre groupe d’utilisateurs pourrait obtenir un résultat de Story Mapping différent.