Après le recueil du besoin auprès des utilisateurs, le Product Owner rédige les Features, les Users stories (US) et les priorise dans un backlog. Cette priorisation est faite en fonction de la valeur apportée et non en fonction du parcours utilisateur dans l’application. Donc en lisant le backlog US par US on n’arrive pas facilement à faire le lien entre elles et reconstruire l’histoire du besoin de l’utilisateur. Les développeurs réalisent donc une petite partie de l’histoire à chaque fois et ils peuvent perdre de vue l’objectif final. Pour pallier à ce manque de visibilité et maximiser la valeur du produit, le PO profite des séances de grooming pour contextualiser les US mais il existe également un autre outil de représentation d’US sous forme de map qui se nomme “Story mapping”.
Le Story mapping
Le Story mapping est un outil permettant d’organiser et prioriser les besoins pour ne pas perdre de vue l’ensemble de l’histoire du besoin utilisateur (Big Picture). Il se réalise au cours d’un atelier collectif avec les acteurs du projet afin d’identifier le besoin, de partager la même vision et de planifier le déroulement de la réalisation du produit. En priorisant par valeur et en délivrant des petites fonctionnalités de manière itérative, on réduit nos risques. Soit le produit répond au besoin et dans ce cas on apporte le plus de valeur dès les premières livraisons soit le produit n’est pas viable et dans ce cas on s’en rend compte rapidement ce qui minimise son coût.
Jeff Patton : “Minimiser l’effort, maximiser le résultat”.
Le déroulement
Un Story mapping est l’histoire de notre produit, on va le construire chapitre par chapitre en suivant les activités de nos utilisateurs. Chaque chapitre va exprimer une activité que l’utilisateur réalise en relation avec le produit. Ces activités seront ordonnancées en fonction du parcours utilisateur sur une ligne horizontale.
Je prends comme exemple l’histoire d’un utilisateur d’un site e-commerce : l’utilisateur va d’abord rechercher un produit, ensuite il va le visualiser, peut-être l’ajouter dans son panier donc il a besoin de gérer son panier. Pour aller plus loin, il va créer un compte pour pouvoir recevoir des offres promotionnelles et avoir la possibilité de payer son produit.
Maintenant que nos chapitres sont identifiés, on va les décomposer sur un axe vertical. Le but est de lister les sous activités nécessaires pour la complétude du chapitre. Ces sous activités correspondent aux US, elles racontent une histoire courte et elles sont priorisées par la valeur.
Si je reprends l’histoire de l’utilisateur du site e-commerce qui cherche un produit, il veut pouvoir faire la recherche par mot clé, filtrer par prix, supprimer les critères de recherches et filtrer par marque. Ce qui lui apporte le plus de valeur c’est la possibilité de chercher par mot clé donc on va commencer par réaliser cette fonctionnalité en priorité.
Il ne faut pas oublier les dépendances entre les fonctionnalités. Par exemple l’utilisateur ne peut pas payer un article s’il ne peut pas l’ajouter à son panier.
On a donc deux axes :
– Un axe horizontal listant les activités en suivant le flot de narration
– Un axe vertical listant les US pour chaque usage ordonnancées par valeur apportée
Le plan de release
Une fois les US priorisées, on peut commencer la planification de manière à réaliser les US qui apportent le plus de valeur en premier. Cela nous permettra d’avoir le plan de release. Il est inutile de faire un plan de release sur une longue durée car le besoin évolue et les priorités également.
Le paiement par PayPal et la connexion via Google sont des fonctionnalités qui ont besoin d’une étude de faisabilité. On peut envisager donc une étude technique avant le lancement de la réalisation du lot 1. Cela permettra de dé-risquer le projet le plus rapidement possible.
Un Story mapping est le fruit d’un atelier collaboratif, il dépend donc des participants et de leurs interactions. Ce qui veut dire qu’un même produit peut avoir plusieurs Story mapping différents.
Une fois le Story mapping est réalisé, il ne faut pas hésiter à supprimer et ajouter des fonctionnalités, les dé-prioriser ou les prioriser, en effet le Story mapping évolue tout au long du projet. On peut également ajouter d’autres informations pour les US, par exemple : “Done” pour les US réalisées, “NFR” pour les US techniques.
