User Story Mapping et Psychologie ? et mes conseils!

J’ai blogué sur la technique du story Mapping, une technique assez répandue comme pratique des équipes agiles. J’ai été tout de suite impressionné par les étapes de construction d’un story map. Je voyais le pouvoir énorme de cette activité, sans pouvoir expliquer le pourquoi.

Aujourd’hui, après quelques années d’essai et d’observations dans les équipes que je côtoie, je pense comprendre d’ou vient justement le pouvoir d’une telle activité. Je voudrais partager  le résultat avec vous chers lecteurs. Je partagerai aussi quelques remarques et conseils, qui vous aideront à mieux bénéficier de cette excellente activité.

Qu’est ce qu’un story map n’est pas?

Un story map n’est pas une carte de catégorisation en fonctionnalités. Ce n’est pas non plus une carte exposant les choses à faire pour réaliser le produit (tâches). Aussi, un story map n’est pas une arborescence de besoins du PO.
Attention, je ne remets pas en doute la valeur de telles exercices et cartes, je dis tout simplement qu’un story map est un autre exercice, qui répond à un autre besoin.

Qu’est ce qu’un story map

Un story map est un arbre qui exprime les parcours en étapes visualisant les fonctionnalités de votre produit, tout en mettant en perspective les différents acteurs et leurs objectifs, les gains business (outcomes) par priorité, ainsi que le minimum à avoir (Less Than Minimum) comme stories (user stories) pour chaque outcome.

C’est une activité en Amont de votre processus de développement.

Un story Map sert essentiellement dans la phase de découverte, et non dans la phase de livraison. C’est une activité qui sert essentiellement à construire et visualiser votre idée. Donc, C’est l’un des premiers exercices avec lesquels vous devriez commencer.

Vous pouvez vous servir du mapping pour déterminer votre budget, mais il y’a un risque de tomber dans de détails non nécessaires. Idéalement, cet exercice prendrait lieu après avoir déterminé votre business Case. (Référez vous aux étapes de stratégie de produit pour plus d’information sur les étapes en amont)

C’est principalement une Activité collaborative

Puisque c’est un exercice de découverte, il faut idéalement inclure :
– Le client (ou un représentant du client)
– Le Product Owner
– un ou des représentant UX
– un ou des représentant de votre équipe d’architecture ou de développement
– un facilitateur qui connait bien la méthode du mapping.

Et le plus important, Elle se construit principalement via le telling

L’objectif d’un story map est d’imaginer et de visualiser à quoi pourrait ressembler le produit une fois bâti. Le mot Story fait référence essentiellement au « telling » (raconter) qui permet à chaque personne participant de se faire une image mentale de la fonctionnalité, l’étape, l’intéraction utilisateur, l’action que le système fait etc. Il est très important de se concentrer sur le telling, et de ne pas tomber dans des concepts abstraits. J’ai vu plusieurs exercices de mapping perdre leur valeur du à l’absence du telling, les rencontres se transformaient très rapidement en rencontres de tâches techniques, de jalons de réalisation etc.

Voici le point clé qui fait toute la différence entre la technique du story mapping et les autres techniques d’analyse.
Si vous prêtez attention aux étapes de construction d’un story map décrits dans ce post, vous remarquerez qu’on ne commence pas par la détermination des besoins à haut niveau. Il y’a une raison pour ça. La raison est tout simplement psychologique. Ceux qui connaissent la PNL (Programmation Neuro Linguistique) savent qu’il existe une notion appelée « Ancrage »

L’ancrage

En psychologie, l’Ancrage est une forme de biais cognitif qui fait que nous nous fixons à la première idée que nous recevons; quelque soit l’importance des idées qui viendront par la suite. La première idée devient inconsciemment notre « standard ». Chacun de nous utilise son propre modèle mental pour visualiser un concept. Quand quelqu’un nous présente un concept, nous visualisons généralement une image mentale de ce concept. Au fur et à mesure que les concepts reliées s’ajoutent, elle sont jugées, construites ou comparées au premier.

Alors, deux choses à retenir ici :
– Bien que la collaboration aide énormément les personnes à se synchroniser, les images mentales pour un seul concept peuvent être différentes.
– la première image mentale que chaque personne se fait du concept, de l’idée ou du produit à construire est extrêmement importante!

Qu’est ce qui se passe maintenant si cette image est assez floue, une idée à « haut niveau »? La réponse est évidente, chacun des participants à l’activité se fait une image mentale très différente des autres. Et c’est le piège dans lequel tombe la majorité quand ils essayent soit
– de partir des besoins à haut niveau et les diviser en petits besoins; soit
– de partir des fonctionnalités et les diviser en sous fonctionnalités; soit
– de partir d’une solution technique.

C’est la ou réside toute la force du story mapping. Le hint est le suivant :
1. Trouver le niveau le plus concret possible afin que tous les participants aient la même image mentale, ou presque. Et c’est pour cette raison qu’il est essentiel de raconter, d’utiliser des visuels, de ne pas hésiter à décrire à quoi ressemblent les interfaces. La meilleure façon reste le sketching on the Fly, si possible.
2. Itérer par la suite soit en remontant (déterminer le besoin de l’utilisateur), en faisant de l’abstraction, si l’histoire est très concrète; ou avec plus de détails sur l’histoire (des stories plus détaillés) si elle est encore très floue.

Si vous avez compris ce point, vous devriez tout de suite voir que c’est la même raison pour laquelle on conseille fortement en Agile à faire du TDD, BDD, Spécification par l’exemple etc. Dans toutes ces pratiques, la même « magie de l’inconscient » se manifeste! Fascinant n’est ce pas?

Conseils

Voici en fin quelques conseils pour ceux qui désirent vraiment apprendre et tirer la valeur de cette activité :
1. Faites cette activité dans votre cycle d’exploration, tout en amont, quand vous construisez votre idée. Le map résultant aidera votre équipe à avoir une image assez concrète de votre idée.
2. N’utilisez pas cette activité pour faire du tasking. Faisant ainsi, elle perd tout son sens.
3. Comme première étape, Concentrez vous principalement sur l’histoire et le telling. C’est loin d’être une perte de temps.
4. Ne commencez jamais à spécifier des besoins de haut niveau. Cela crée plus de chaos dans la tête de chacun de vos interlocuteurs.
5. Ne Conceptualisez pas lors de l’exercice. Gardez vos concepts pour des exercices dédiées à la conception.
6. Si vous êtes novice, il est important de suivre la recette telle que décrite ici : http://www.berejeb.com/2016/02/construisez-votre-user-story-map-en-5-etapes-faciles-une-autre-facon-de-representer-le-backlog-de-produit/ . Ne vous inquiétez pas, vous pourrez créer votre version modifiée par la suite.

Voila. Si vous avez des questions concernant ce sujet ou d’autres, que vous voulez échanger, ou que vous n’êtes pas d’accord, n’hésitez pas à m’en faire part sur Twitter ou sur Linkedin