J’ai eu le plaisir de lire dernièrement la traduction du livre de Jeff Patton sur le Story Mapping (merci à Dunod pour ce cadeau de Noel). Claude Aubry en a écrit la préface, après avoir écrit celle de la seconde édition de mon livre kanban.

Impression générale

Le livre est assez long, 240 pages, mais il se lit bien. C’est principalement un livre pour Product Owner, pour à la fois mieux comprendre son rôle et améliorer ses pratiques. Mes impressions sont plutôt bonnes, le livre est intéressant, surtout pour l’état d’esprit et le pourquoi des choses. Il (re)donne beaucoup de sens. Il revisite l’agilité au travers la pratique du Story Mapping. Du coup, le bémol du livre est la répétition et la dilution de ses messages. On ne commence pas par son livre, choisissez plutôt l’excellent livre de Claude sur Scrum, puis faites un zoom avec celui de Patton. Il y aura alors quelques informations déjà connues du lecteur, et un peu de redite mais avec une perspective (celle des utilisateurs plus que celle de la méthode) un peu différente. Malgré cela, le livre vaut le coup d’être lu. Je vous en propose quelques morceaux choisis :

D’abord les stories

Le véritable but des stories est la compréhension mutuelle

Pour ma part, c’est un des véritables buts, sans en être le seul. Un entrepreneur développant son produit seul aura également un intérêt à découper son besoin en stories, pour d’autres raisons. Jeff nous rappelle l’origine des stories par Kent Beck, et de leur process par Ron Jeffries avec les cartes CCC (carte > conversation > confirmation), rappelant ainsi que l’implémentation d’une fonction/solution commence par une conversation avec le Product Owner. Et on ne le dira pas suffisamment :

Les bonnes conversations des stories concernent les utilisateurs et leurs motivations et pas simplement la technique

Puis le story Mapping

J’ai découvert le Story Mapping il y a longtemps, en 2010 je crois, lors d’un atelier à la conférence SPA à Londres sur les personae. Ce n’est pas un hasard, car le Story Mapping renforce l’idée leur utilisation. Techniquement parlant, le Story Mapping sert à :

Décomposer les grandes stories quand vous en discutez

C’est donc un des ateliers de base, que l’on utilise régulièrement lors d’un projet agile, surtout lors du sprint 0. Il sert à initialiser le Product Backlog à partir des features ou epics, puis le raffiner. L’intérêt est de passer de macro fonctionnalités aux plus petites fonctionnalités (les stories), sans en oublier. Car si les stories sont vraiment la bonne granularité pour piloter un projet agile, elles donnent une vision trop fragmentée d’un produit. Voir un projet agile par le biais des stories n’est pas suffisant. D’où l’idée de s’outiller pour décomposer les besoins utilisateurs en fonctionnalités plus atomiques.

Le principe du story mapping

On décompose un besoin (la carte bleue à gauche) d’abord dans sa largeur (les cartes vertes en haut). Ce sont les grandes étapes qui permettent de réaliser un processus, les grandes catégories d’un besoin. Cette ligne sert de colonne vertébrale à l’atelier mais également de flux narratif, pour raconter l’histoire de l’utilisateur. Puis, on se consacre à la profondeur du besoin, verticalement, c’est à dire le détail et les options, les variations, les alternatives, comprenez les stories. Ce sont les cartes jaunes de l’exemple. L’agilité, l’ajustement de la solution, se loge réellement à ce niveau-là.

Priorisation et Lean startup

A ma grande (et bonne) surprise, il parle même de Lean startup. Insistant sur le fait qu’une idée n’est qu’une hypothèse, tant qu’elle n’est pas validée par ceux qui vont effectivement utiliser leur solution. C’est l’état d’esprit que doit partager un bon Product Owner avec un entrepreneur, celui de créer moins pour créer mieux, qu’il exprime par :

Minimisez l’output, et maximisez l’outcome et l’impact

L’étape suivante de l’atelier de Story Mapping est naturellement la priorisation des user stories. Jeff Patton rappelle avant tout qu’il ne faut pas prioriser les features mais leur impact, pas le Je veux <>, mais le afin de <> des stories ! Ce premier niveau de priorisation est affiné par rapport à l’apprentissage qu’une story va nous apporter, car on rappelle que ce ne sont que des hypothèses. Kent Beck a d’ailleurs proposé une révision du Manifeste Agile en ces termes :

L’apprentissage validé prime sur le logiciel opérationnel (ou une documentation exhaustive)

Pour prioriser, on tire un trait horizontal, pour distinguer visuellement ce qu’il est nécessaire d’avoir si on veut aller en production, de ce qui est optionnel. Pablo Pernot appelle cette première ligne le « ça fait mal mais ça marche » :o). Pour les lignes horizontales, Jeff Patton propose plusieurs manières pour les définir :

Au niveau roadmap

1. Release actuelle
2. Releases suivantes
3. Idées à long termes

Au niveau plan de release

1. Pour voir que ça fonctionne
2. Pour améliorer
3. Pour permettre la livraison
4. Si on a le temps

J’ajoute la version Lean startup

1. Le Minimum Viable Product
2. Les options ou Minimum Marketable Feature

Rôle du Product Owner et de l’équipe

Jeff Patton rappelle le rôle du Product Owner dans une équipe qui

à lui seul, ne peut pas écrire toutes les stories et être présent à toutes les conversations et orchestre le travail de découverte du produit

Et donc, ouvrez bien grands vos yeux amis managers qui pensez qu’un équipe Scrum se réduit aux seuls développeurs, ou MOA qui ne pensez souhaitez pas faire partie d’une telle équipe : Se trouve dans l’équipe Scrum toutes les bonnes personnes pour cette découverte produit, ce qui inclut des experts en expérience utilisateur, en conception et en technique. On a donc des sachant métiers, des UX designers, … Ceux que Jeff appelle les casseurs de blocs (les grandes fonctionnalités). Il y a tout cela dans ce livre et bien d’autres choses. Mais avant tout, il vous donne les clés d’un atelier agile indispensable : le story mapping.