[2/4] - Comment bien démarrer un projet : organiser les besoins grâce au Story Mapping

Temps de lecture estimé : 5 min

Cet article fait partie d’un groupe d’articles visant à bien préparer le backlog du premier sprint d'un projet avant de commencer à développer. C’est le deuxième article de la série, si vous avez manqué le premier le voici : Comment bien démarrer un projet : la découverte du domaine avec le Domain Storytelling

Bonne lecture !

Comme nous l’avons vu dans l’article précédent, le Domain Storytelling nous a permis de “dégrossir” le projet de façon visuelle, grâce aux Domain Stories.

Ces Domain Stories ont pour objectif d’expliciter la façon dont communiquent des gens ou des systèmes entre eux.

Dans le cadre du projet CraftOverflow, clone simplifié de StackOverflow, nous avions visualisé deux Domain Stories :

Trouver la réponse à une question :

Poser une question afin d’obtenir une réponse :


Le Domain Storytelling est donc une méthode pour mettre en évidence des besoins fonctionnels.

Il nous faut maintenant une méthode pour rédiger ces besoins, ainsi qu’une méthode pour les organiser.

User Story Mapping

L’atelier de User Story Mapping (ou Story Mapping) suit logiquement celui de Domain Storytelling dans la mesure où l’on souhaite maintenant rédiger les besoins, tout en se basant sur le récit de chaque scénario.

Nous allons utiliser les User Stories comme support pour rédiger les besoins, et la Story Map sera le support pour l’organisation et la priorisation de ces stories.

Qu’est-ce qu’une User Story (US) ?

Une User Story est un support de communication au sein d’un projet.

Elle sert à ouvrir la discussion autour des besoins d’un produit, en formalisant ces besoins du point de vue de l’utilisateur final, le tout sous forme de micro récit. D’où le nom de User Story.

Il existe plusieurs formats pour ces fameux micro récits, je ne vais pas m’étendre sur le sujet cela dépasse le périmètre de cet article, mais l’une des formes les plus utilisées aujourd’hui est celle-ci :

En tant que <type d’utilisateur>, je veux <atteindre un objectif> afin de <une certaine raison>

De la séquence d’une Domain Story à la User Story

Pour “traduire” une Domain Story en User Story, il suffit d’utiliser les symboles utilisés dans la Domain Story :

En tant que <actor>, je veux <activy + work object> afin de …

On voit donc apparaitre ici les notions de actor, d’activity et de work object.

Comment trouver la partie <une certaine raison> ?

Parfois, les indications mises à côté des symboles de la Domain Story peuvent donner une piste.

Sinon, c’est juste un bon prétexte à la discussion pour “clarifier” le “pourquoi” de l’action.

Maintenant que vous voyez comment établir une User Story à partir d’une séquence d’une Domain Story, voyons à présent comment organiser tout cela grâce au Story Mapping.

De la Domain Story au Story Mapping

Le Story Mapping est un atelier permettant de dresser la liste des fonctionnalités d’un produit en effectuant le récit d’actions des différents utilisateurs.

Il se différencie du Domain Storytelling dans le sens où toutes les granularités se mélangent, et qu’on ne voit pas visuellement la collaboration entre les différents acteurs.

Pour autant, c’est un format très pertinent pour organiser ces besoins fonctionnels et les prioriser.

Une Story Map à une dimension horizontale représentant la temporalité : on lit l’histoire de l’utilisateur de gauche à droite.

Sa dimension verticale correspond aux différents degrés de contexte. De haut en bas :

  • Le type d’utilisateur

  • Ses activités sur le site

  • Les tâches qu’il doit réaliser au sein de ces activités

  • Les User Stories formalisant le besoin

Enfin, les User Stories sont classées, elles aussi, verticalement de la plus “prioritaire” à la moins prioritaire.

L’objectif étant de déterminer un premier backlog pour le premier sprint et d’éventuelles pistes de backlog pour les prochains.

Pour en savoir plus sur les User Stories et le Story Mapping je ne peux que vous conseiller le livre de Jeff Patton : User Story Mapping

La Story Map de CraftOverflow

Reprenons l’exemple de la première Domain Story : trouver la réponse à une question.

Plus particulièrement, intéressons-nous à la première séquence :

dev consulte une question dans la liste des questions

On commence donc par poser l’acteur et l’activité :

Vous noterez que je ne mentionne pas “dans la liste des questions”, car c’est déjà un niveau de détails trop gros. Ici nous sommes juste intéressés par l’activité très générale d’un-e développeur-euse souhaitant consulter une question.

On peut procéder de la même façon pour les autres séquences :

J’ai renommé légèrement la dernière séquence pour rester à un niveau de détails plus grossier, sans parler tout de suite de la notion de feedback positif. C’est un feedback au sens général.

On retrouve l’aspect “récit”. L’horizontalité indiquant la temporalité, on peut facilement lire :

“Dev consulte une question (puis) consulte une réponse (puis) exprime son feedback sur la réponse”

Maintenant que les activités sont définies, on peut descendre d’un niveau de granularité pour aborder les tâches : les actions que l’utilisateur va devoir faire au sein de son activité.

Commençons par indiquer les tâches que l’on connait déjà grâce à notre Domain Story :

Pour aller plus en détails, on peut directement continuer en ajoutant des tâches dans la Story Map, ou l’on peut retourner du côté du Domain Storytelling pour procéder au récit de scénarios plus “fins” et précis. C’est une question de préférence, en fonction des personnes concernées et en présence (si l’atelier est fait en présentiel) et du besoin potentiel de visualiser la collaboration entre les “acteurs”.

Dans l’article précédent, nous avions vu une Domain Story plus détaillée pour ce scénario :

Grâce à cette Domain Story, de nouvelles tâches font leur apparition :

Comme vous l’avez peut-être remarqué, une nouvelle tâche a fait son apparition pour l’activité “exprime son feedback sur la réponse” : commenter la réponse.

Cette notion de commentaire n’était pas apparue dans le Domain Storytelling, et ce n’est pas grave. Rappelez-vous que le but de ces ateliers est de faire émerger les besoins métier, donc si vous avez une bonne idée lors d’un atelier de Story Mapping ne vous privez pas de la mentionner, au contraire !

À tout moment vous pouvez passer du Domain Storytelling au Story Mapping et vice versa, c’est tout l’intérêt : l’agilité et la souplesse !

Maintenant que les tâches sont définies, on peut commencer à rédiger quelques User Stories (cliquez sur l’image pour la voir en grand) :

Voilà nos premières User Stories !

Nous avons déjà fait un grand pas dans la préparation de notre projet, mais pour être le plus efficace possible, il va falloir prioriser ces User Stories.

L’objectif est de livrer continuellement de la valeur pour avoir une boucle de feedback la plus rapide possible.

Si les User Stories sont trop grosses, il se passera trop de temps entre le développement et la mise en production, ce qui peut faire perdre énormément de temps et d’argent.

Comment remédier à ce problème ? En découpant les User Stories !

C’est ce que nous verrons dans le prochain article :)

Happy Coding !