Le Story Mapping – aussi appelé User Story Map en anglais – est une technique utilisée dans le développement agile de logiciels pour organiser et prioriser les histoires utilisateurs, qui sont de courtes descriptions de la fonctionnalité souhaitée d’un produit ou d’un service.
Une user story est une description simple et compréhensible d’une fonctionnalité logicielle telle que l’imagine l’utilisateur et telle qu’il la décrit.
« Les stories tirent leur nom de la manière dont elles doivent être utilisées, et non pas de leur contenu. » , Jeff Patton (« Le story mapping : visualisez vos users stories pour développer le bon produit »)
Anatomie d’une Story map
En haut d’une Story Map, nous avons la « colonne vertébrale » qui a parfois plusieurs niveaux (une épaisseur). On y représente le flux narratif, y compris les variations et tâches alternatives.
L’axe vertical, de son côté, permet de visualiser les releases.
Concrètement, cela consiste à faire des tranches horizontales composées de post-its que l’on place et déplace au fur et à mesure vers le bas, sous la tranche supérieure. De cette manière, il est facile d’identifier les tâches dont on a besoin pour atteindre un résultat ou un bénéfice particulier.
La première release, c’est-à-dire la première tranche juste en-dessous de la colonne vertébrale décrivant le flux narratif, correspond au Minimum Viable Product (MVP). Puis, plus on va vers le bas, plus cela signifie que les User Stories (US) peuvent attendre – chaque tranche étant donc une release particulière du produit cible.
Le mapping de ces US consiste à placer celles-ci dans une carte en deux dimensions avec un axe horizontal chronologique dans lequel l’utilisateur va se servir des différentes fonctions, et avec un axe vertical qui matérialise la priorité de ces fonctions.
L’une des idées fortes de cette méthode est de prôner un dialogue approfondi, concret et très en amont entre les futurs utilisateurs et les concepteurs de logiciel sur ce qui est attendu du futur produit.
Le story mapping est donc une méthode de compréhension mutuelle des spécifications d’un logiciel qui vient en complément des méthodes agiles telles que Scrum. Elle a été conçue par Jeff Patton, que je vous ai cité plus haut sur la signification et l’usage des user stories.
Ces cartes sont généralement utilisées pour créer une représentation visuelle du parcours de l’utilisateur dans un produit, chaque histoire d’utilisateur (US) représentant une étape ou une interaction spécifique le long du parcours, et le plan itératif et incrémental de construction du produit.
L’un des avantages du story mapping est qu’il aide les équipes à comprendre l’expérience globale de l’utilisateur et à hiérarchiser le développement des caractéristiques et des fonctionnalités les plus importantes.
D’ailleurs, une façon courante d’utiliser des US consiste à en établir une liste, à les hiérarchiser et à commencer à en parler, puis à les transformer en logiciel, une par une.
Comment construire une Story map ?
Penser – Écrire – Expliquer – Placer
Quand vous travaillez avec vos contributeurs pour construire une story map, ou quand vous avez des discussions sur un sujet quelconque, créez une visualisation simple pour noter le contenu de la discussion.
En effet, comme le dit l’adage : « Les paroles s’envolent, les écrits restent ».
L’une des erreurs à éviter consiste à ne surtout pas laisser s’envoler les idées. Or, ce qui se produit souvent, c’est que les idées ne sont pas décrites et personne n’y fait plus référence. Puis plus tard, elles refont surface, et il faut à nouveau tout expliquer car les gens ont oublié ou n’ont pas vraiment écouté.
Une bonne pratique pour faire du Story Mapping est donc :
- D’écrire sur un post-it quelques mots sur votre idée, immédiatement après y avoir pensé,
- D’expliquer votre idée aux autres, de faire des dessins, de leur raconter l’histoire,
- De placer les post-its dans un espace de travail partagé où tout le monde peut les voir, les déplacer ou en ajouter.
Si tout se passe bien, il y aura beaucoup d’autres idées qui viendront enrichir la User Story map initiale.
Une seconde bonne pratique est de décrire précisément les clients et utilisateurs, puis de raconter le flux narratif représenté par les US en se positionnant de leur point de vue.
Cela permet :
- De déplacer les post-its de manière plus pertinente, en les réorganisant de gauche à droite.
- De s’assurer d’une compréhension mutuelle.
- De détecter les « trous dans la raquette » de votre pensée.
Épaissir la Story Map
Une fois que la largeur de la User Story Map est en place, on peut commencer à l’épaissir.
Cela ne signifie pas qu’on va réfléchir à sa planification, mais que l’on recherche à combler les lacunes de notre compréhension.
On s’arrête donc à chaque étape de la Story Map et on se demande :
- Quelles sont les choses spécifiques que les utilisateurs feraient ici ?
- Quelles sont les autres choses qu’ils pourraient faire ?
- Qu’est-ce qui rendrait l’application vraiment meilleure ?
- Que se passera-t-il si quelque chose se passe mal (notion de story alternative) ?
Le résultat de ce Story Mapping est que nous avons sous les yeux la journée ordinaire d’un utilisateur ou d’un client, et décrit ce qui pourrait favoriser sa réussite.
Pour résumer, le story mapping consiste à avoir une conversation, à la noter de gauche à droite sous forme de post-its ou de cartes. Puis de haut en bas, on note les détails. Contrairement aux approches traditionnelles de gestion de projet, où chaque nouvelle demande augmente le périmètre produit – on parle en général d’inflation du périmètre -, en agile on parle d’augmentation de la compréhension.
Décomposer une road map en releases
A la fin du processus, on obtient une stratégie de releases incrémentales qui permet de commencer à travailler, de telle manière que chaque nouvelle release apporte de réels bénéfices.
A gauche, de haut en bas, on a donc le nom de la release concernée, puis de gauche à droite, les US à développer.
Ce n’est donc pas une simple liste de fonctionnalités empilées à coder, mais une liste des avantages réels.
Se concentrer sur l’impact cible spécifique est le secret pour hiérarchiser le travail de développement.
A retenir
Ne hiérarchisez donc pas les features, mais leur impact !
Comment faire une bonne planification de la Story Map ?
- Tout d’abord, sélectionnez bien vos SME (Subject Matter Experts, les « sachants », selon la définition de IIBA®). Faites réaliser le story mapping par des contributeurs qui savent de quoi ils parlent.
- Ensuite, gardez en mémoire qu’on ne livre pas obligatoirement chacune des releases. Elles peuvent juste être une étape importante pour le projet, mais pas du point de vue des utilisateurs (autant éviter les ennuis…). Par exemple on commence par le MVP qui va effectivement être livré (le squelette fonctionnel), puis on poursuit avec une release permettant de l’améliorer – mais qu’on ne livre pas. Et enfin on continue avec une troisième release, qui est composée de US permettant la livraison.
- Retenez qu’une estimation reste approximative. Ce qui permet de la sécuriser, ce sont les mesures. Plus souvent on mesure, mieux on saura prévoir. Donc… il faut décomposer suffisamment pour réussir à mesurer.
- Enfin, dans la suite logique du point précédent, gérez votre budget en estimant le temps imparti par tâche, et en vous attaquant le plus tôt possible à ce qui pourrait faire exploser le budget grâce à la mise en place de la gestion des risques projet.
Quand faire du Story Mapping ?
Il existe plusieurs situations dans lesquelles il peut être approprié de réaliser une Story Map :
- Lorsque vous avez besoin de comprendre l’expérience globale de l’utilisateur et de vous assurer que le produit est développé de manière intuitive et facile à utiliser.
- Lorsque vous avez besoin de prioriser le développement des caractéristiques et fonctionnalités les plus importantes, en veillant à ce que les efforts soient concentrés sur le travail le plus utile.
- Lorsque vous devez planifier et hiérarchiser des itérations à court terme au sein d’un produit ou d’un service spécifique, ce qui les rend utiles pour le développement de logiciels agiles.
- Lorsque vous utilisez une méthodologie agile, telle que Scrum ou Kanban, pour guider le processus de développement et prioriser le travail.
Vous l’aurez compris : le Story Mapping est un outil précieux pour le développement agile de logiciels et peut aider les équipes à livrer des produits de haute qualité qui répondent aux besoins de leurs utilisateurs.
