Club de lecture #3 : User story mapping
Allez, 3ème club de lecture autour du très connu "User story mapping" de Jeff Patton.
POUR QUI ?
Pour tout profil d’une équipe qui cherche une façon de s’aligner sur la compréhension d’un besoin. Mais j’aurais actuellement plutôt envie de le mettre dans les mains des PO que je croise. Qui perdent parfois la tête dans les kilomètres de leur backlog. Et aussi dans les mains des développeurs à chaque fois que je les entends se plaindre en disant : “les stories sont écrites n’importe comment”.
POUR QUOI ?
Pour résoudre l’éternel problème de la compréhension entre individus. Pour réintroduire la discussion entre les membres d’une équipe. Et pour éviter de construire un produit qui ressemble à Frankeinstein : construire un produit pièce par pièce est une bonne technique de développeur mais pas de design produit.
Tout simplement pour savoir comment utiliser ce super outil qu'est la user story map.
J’AI BEAUCOUP AIMÉ
L’absence de compréhension mutuelle illustrée par les râtés sur Cake Wrecks.
L’idée que des documents partagés n’assurent pas une compréhension partagée.
Le morning map exercice : pour entraîner les gens à raconter une histoire et surtout définir un MVP. (Demandez aux gens de raconter toutes les tâches qu'ils réalisent entre le moment où le réveil sonne et le moment où l'on ferme la porte à clef).
L’exercice du fish bowl pour assurer une conversation de qualité quand beaucoup de monde autour de la table.
L’idée que l’on n’a jamais assez de temps et d’argent pour tout faire. Je pense que de le répéter tout au long du projet, et surtout au début, peut stresser un peu les PO qui ont du mal à prioriser (surtout valable dans les contextes où le PO n’est pas le détenteur du budget).
LES TIPS
Faire parler les gens et écrire ce qu’ils disent sur des fiches : talk and doc
Demander au PO avant de démarrer l'exercice : si tu ne pouvais satisfaire qu’un seul utilisateur, lequel serait-il ?
Parler à la place de l’utilisateur et lui demander de raconter son utilisation de l’outil en utilisant des verbes.
Aller jusqu’à la fin de l’histoire plutôt que de se perdre dans les détails (de gauche à droite).
Positionner les risques sur la story map
Utiliser le template de story : who/what/why
Parler de product discovery et non de backlog grooming
Faire tester l'outil. Les démos ne suffisent pas. C’est comme regarder une voiture dans une vitrine. Il faut la tester pour savoir si elle nous convient.
LES CITATIONS QUE JE RETIENDRAI
“Requirements mean shut up”.
“Great art is never finished, only abandoned” Leonardo da Vinci.
Pas grand chose d’autre à dire sur ce bouquin. Je le ré ouvrirai probablement pour piocher des idées. L'essentiel du bouquin est contenu dans le premier tiers : 8 chapitres de trop. C’était sympa de pouvoir en discuter avec Jean-Claude Grosjean, notre guest star du jour, qui utilise l'outil régulièrement.