Commençons par un story mapping

Si il y a une chose difficile pour beaucoup d’entreprises, c’est de lancer un nouveau projet en décidant de se mettre à l’Agile alors que l’entreprise a d’autres méthodes de fonctionnement pour ces projets. C’est là que la user story mapping inventé par Jeff Patton va intervenir.

Comment passer d’un cahier des charges à des user-story ? Comment se lancer dans la création d’un backlog ? La transition n’est pas toujours simple et l’utilisation de méthodes intermédiaires peut aider le “nouveau” Product Owner a réussir à créer son premier Backlog.

Certains Product Owner utilise cette méthode également pour chaque nouveau projet vu son efficacité pour créer une première vision claire du produit final.

Une vue rapide du projet

Le Story Mapping a pour but d’avoir rapidement une vision globale du projet de façon macroscopique. On va proposer au Product Owner de remplir un graphique simple qui aura la notion de priorité en axe vertical et de temps en axe horizontal (la notion temps s’affinera avec le temps, au début faut pas trop s’en préoccuper).

Story Mapping
User Story Mapping

L’idée de ce graphique sera de représenter les besoins utilisateurs d’un nouveau produit. Nous allons définir les usages de l’utilisateur cible et les représenter selon les priorités que nous désirons appliquer.

Comme l’Agile l’exige (le recommande grandement), utilisez des post it de différentes couleurs pour créer votre user story mapping. La création de ce story mapping est un moment agréable et ludique qui permettra d’en déduire un backlog complet.

Ce concept a pour but d’éviter les réunions dans tous les sens qui ne font avancer les choses que par petits paliers. En général le Story Mapping est tellement visuel que quelques séances suffisent pour avoir une première vision du produit final désiré.

Premier backlog du Product Owner

Il y a de nombreux Product Owner (PO) aujourd’hui qui découvrent leur rôle. L’agilité se popularise dans les entreprises et de nombreux nouveaux PO se forment sur de nouveaux projets.

Le PO qui aura créé la description courte des besoins utilisateurs aura beaucoup plus de faciliter à créer ses user-story car elles seront souvent la traduction de ces besoins dans la formule plus structurée “En tant que… je souhaite … afin de …”.

Le Product Owner aura créé son premier backlog sans difficulté grâce à cette méthode et aura même accéléré sa création.

Comment créer mon user story mapping ?

Le Scrum Master ou le Coach Agile va proposer un petit board avec les deux axes horizontales et verticales et proposera des post’it de deux couleurs au Product Owner pour séparer les activités et le découpage de ces activités. (exemple en image en début d’article)

Le Product Owner va pouvoir mettre horizontalement en haut, les premiers jets de son analyse de l’activité fonctionnelle de son futur produit dans une couleur de post’it : (scénario, pages sans détail…). Proposer au Product Owner de voir quel premier découpage est le plus sensé pour son futur produit.

Pour que ce soit bien visuel, il est conseillé que cette première ligne soit dans une couleur de post’it différente.

L’idée n’est pas d’avoir le résultat final mais de créer une première vision que le Product Owner pourra affiner. Il est plus facile de travailler quand il y a une première vision qui se dégage.

Ensuite on demandera au Product Owner de détailler ces activités de haut en bas (haut étant l’activité la plus importante) correspondant au premier découpage de ces activités par story. L’avantage des post’it est de pouvoir les redéplacer au fur et à mesure.

Le premier travail de la user story mapping a pour but de faire un premier jet, il ne faut pas le complexifier au risque de perturber la vision du Product Owner.

Faire des story INVEST

Le coach Agile s’assurera que les story (pas forcément user-story dès le début) respecteront le concept des story INVEST (acronyme vu dans l’article du découpage des user-story).

Rappel rapide de ce qu’est une story (ou user-story) INVEST :

 

  • I pour Indépendante : chaque user-story doit être indépendante des autres
  • N pour Négociable : les détails doivent être négociables. C’est pour cela qu’on écrit une user-story en une seule petite phrase afin de ne pas forcer les détails
  • V pour Valeur : chaque user story doit apporter de la valeur business pour les métiers ou les clients
  • E pour Estimable : chaque user-story doit être estimable par les équipes de développement ; pour cela, ces équipes doivent bien les comprendre.
  • S pour Suffisamment petite : chaque user story doit être bien découpée afin d’être livrée au sein d’un seul Sprint.
  • T pour Testable : il faut que toutes les user story soient testables.

Nous pourrons rapidement avoir une vision des livrables itératifs possibles (traits bleus sur l’image) du produit pour avancer de façon Agile sur le projet.

Transformation en Backlog

Quand tout ce travail est bien affiné (l’idée étant d’affiner au fur et à mesure), nous aurons un premier backlog complet du projet pour cette fois fonctionner verticalement comem avec un board dédié au Product Owner (article : Le board du Product Owner)

Conclusion

Ce travail de user story mapping est une approche intéressante qui peut souvent être un accélérateur pour démarrer un projet. N’hésitez pas à l’utiliser sur des nouveaux projets pour avoir rapidement une premier vision globale de celui-ci.