Construisez votre « User Story Map » en 5 étapes faciles !

Le backlog de produit traditionnel se manifeste en une pile de récits utilisateurs (user stories) priorisés selon la valeur d’affaire. Cette organisation du backlog de produit a l’avantage de faciliter au product owner la préparation des stories à être développées par l’équipe de développement. Par contre, puisque l’organisation est linéaire, il devient très difficile de faire le lien entre les stories. En n’ayant pas une représentation globale du produit, fonctionnalité ou amélioration que l’équipe est en train de livrer, certains membres de l’équipe vont se perdre dans les “petites” stories qu’ils ont à faire à chaque sprint, et peuvent manquer des opportunités de conversation et de challenge afin de maximiser le ratio travail / valeur d’affaire.

Dans son excellent livre “User Story Mapping”, Jeff Patton présente une alternative à cette représentation. Et ce, en retournant aux concept primordial d’une “user story” qui est le “telling”. Le terme français l’exprime très bien : le récit utilisateur. L’idée est donc de réciter ce que l’utilisateur fait (et bien sur, ce qui a l’intention de faire) quand il utilisera le produit ou la fonctionnalité que nous allons, en tant qu’équipe de développement, lui livrer.

Les user stories tiennent leur essence de ce qui suit : Si nous arrivons, en tant que parties-prenantes dans le développement du produit ou de la fonctionnalité, à avoir une compréhension commune de ce que l’utilisateur fera, quand il utilisera notre produit, nous serons capables de faire notre travail de livraison de ce produit de façon efficace et efficiente”.

Qu’est ce que nous pouvons dégager de l’hypothèse qu’on vient de citer :

1. l’objectif principal des user stories est d’avoir une compréhension commune de l’utilisation de la fonctionnalité.
2. l’exercice d’utiliser les user stories consiste à imaginer l’interaction de l’utilisateur avec le produit.
3. les user stories servent à avoir une compréhension commune entre plusieurs parties prenantes dans l’entreprise et non uniquement l’équipe de développement (contrairement à ce que nous sommes peut être habitués d’entendre : les user stories servent à la livraison. Oui, entre autres, ils servent à la livraison, mais pas uniquement à la livraison).
4. la compréhension commune des user stories à plusieurs niveau nécessite au Product Owner de gérer les niveaux de détail en s’assurant de garder la propriété essentielle du Telling (récit). Ceci est un, sinon le plus gros défi.

Afin de pouvoir se retrouver facilement dans l’histoire, et afin d’avoir des niveaux différents de détail du récit, l’alternative que Jeff Patton propose est de représenter le backlog de produit en une carte (Map).

Quand on regarde la Carte, en lisant les activités (postits verts) de gauche à droite, on est capable de raconter l’histoire de l’utilisateur qui va utiliser notre produit ou fonctionnalité (Flot de narration).

On peut aller dans plus de détails en lisant les user stories (post-its en jaune). Le plus on descend dans la carte, le plus il y’a de détail sur l’activité.
En haut des activités, on retrouve les types des utilisateurs (postits-en bleu) ou rôles. On peut bien évidemment retrouver des rôles système, ou encore avoir deux rôles impliqués dans une même activité.
À gauche, on retrouve les résultats (outcomes) qui représenteront nos objectifs de livraisons (release). Un point très important à souligner ici est que la priorisation se fait plutôt sur les résultats et non sur les fonctionnalités. Dans une entreprise Agile, l’objectif n’est pas de livrer le plus de fonctionnalités. Bien au contraire, le but est de livrer le minimum possible de fonctionnalités (ou mieux, moins que le minimum, mais ça c’est une autre discussion  ) pour atteindre le résultat. Un Bon product owner priorise plutôt les résultats et non les fonctionnalités.

Un exercice collaboratif

Builder la carte est un exercice collaboratif. Un bon product owner table sur la collaboration entre les parties prenantes et utilise les techniques de groupe afin de bénéficier des connaissances et des capacités de créativité et d’innovation. Chez Nuglif, nous faisons des ateliers de mapping en incluant des représentants des utilisateurs, des spécialistes d’interface utilisateurs, des développeurs, des spécialistes de qualité etc. Cette activité est d’une part extrêmement enrichissante autant pour le produit à livrer, que pour chaque personne qui y participe, que pour optimiser le temps de compréhension et de construction du backlog.

Construisez votre « User Story Map »  en 5 étapes faciles

Tout ça est très cool! Mais comment faire donc pour Construire une Carte de Backlog?
Eh bien, voici un exercice simple qui vous aide à cheminer dans cette technique. Je vous joins une partie des slides que j’avais présenté à Agile Montréal en 2015.

[new_royalslider id=”12″]

En résumé

1. Les user stories doivent toujours garder la sémantique de Telling
2. les user stories sont un moyen facile afin d’avoir une compréhension commune entre tous les intervenants.
3. un story map est une meilleure façon d’organiser le backlog du produit.
4. l’activité du story mapping est une activité collaborative.
5. la priorisation se fait beaucoup plus sur la retombée plutôt que sur les fonctionnalités