À n'en pas douter, pour construire aussi bien sa Batmobile et toutes les fonctions qui vont avec, Bruce Wayne s'est servi du Story Mapping !
Aussi appelé User Story Map, il s'agit d'un atelier mis en place initialement au cœur des projets agiles. Mais il a aussi son utilité dans n’importe quel type de projet ou organisation autres que projets informatiques.
Il permet de définir la vision d’un nouveau produit à son lancement ou encore des nouveaux besoins utilisateurs macros de votre produit, à travers une représentation du backlog en 2 dimensions créée collectivement par toutes les parties prenantes à l’atelier.
Ces parties prenantes, qui sont-elles ? Il peut s’agir de tous les membres opérationnels de votre équipe : product owner, product manager, développeur, UX Designer, mais aussi utilisateur, sponsor ou encore client.
Il est recommandé d’avoir une palette représentative des personnes participant à la construction de votre produit.
Et cette représentation du backlog, qu’apporte-elle de plus que le backlog lui-même ? Cette représentation en deux dimensions permet de prendre de la hauteur sur votre produit et de poser sur un axe horizontal la représentation chronologique des étapes d’un parcours utilisateur donné, puis sur un axe vertical les différentes actions à effectuer lors de ce parcours par l’utilisateur (fonctionnalités), afin de pouvoir les prioriser en fonction de leur caractère essentiel pour votre produit.
En dehors du fait d’être très visuelle et de pouvoir parler à n’importe quel membre de l’organisation, elle vous permet également de pouvoir scinder vos différents parcours utilisateurs si nécessaire. Cela permet donc de distinguer beaucoup plus clairement les actions par parcours (et potentiellement, par type d’utilisateur).
Pour construire votre Story Map, vous allez avoir besoin de post-its, d’un mur avec idéalement des bandes collantes pour délimiter vos axes et vos différents niveaux de priorités, uu d’un tableau blanc avec des feutres pour faire de même.
Vous pouvez tout aussi bien vous servir d’outils en ligne tel que draft.io (gratuit) ou Product Craft. Je vais me servir du premier pour illustrer mes propos.
La structure globale d’une Story Map se fait donc sur 2 axes. Vous avez d’abord l’axe horizontal, qui représente le temps et donc le déroulé des actions de ou des utilisateurs dont vous écrivez la Story Map issues de votre User Journey (nous y viendrons à l’étape 2). Vous avez ensuite l’axe vertical, représentant l’ordre de priorité des différents éléments que vous allez rajouter dans votre Story Mapping.
Dans un tout premier temps, nous allons définir les composants qui vont nous permettre de construire une Story Map solide.
Vous devez tout d'abord définir un ou plusieurs personae : quels sont ou seront les utilisateurs de votre produit ou de votre nouvelle feature ? Comment les catégoriser ?
Le mieux, quand il s’agit de projets agiles, est de regrouper vos utilisateurs par type de parcours d’utilisation. Cela vous permettra d’avoir pour chaque persona un seul besoin lié à votre produit, identifiable et clair.
Une fois cela fait, vous allez pouvoir compléter la fiche de votre persona avec quelques informations la définissant :
Pour en savoir plus sur la définition des personae, je vous invite à vous rendre sur le blog de MyAgilePartner.
Après avoir défini les personae de votre produit ou de votre feature, nous allons maintenant écrire leur “User Journey”. Cela va nous aider à poser les premières bases de notre Story Map.
Qu’est-ce qu’une User Journey ? C’est en fait le parcours d’un utilisateur retraçant chaque action à partir du moment où il va arriver sur votre produit jusqu’au moment où il aura atteint son besoin ou son objectif défini dans sa fiche de persona.
Vous allez donc choisir le persona sur lequel vous souhaitez travailler et réaliser sa User Journey.
Pour prendre moi-même un exemple et pouvoir vous illustrer la suite de l’atelier, je souhaite monter un site de streaming de contenu culinaire. J’ai défini 2 personae : le streamer qui vient partager son expertise sur la plateforme de streaming, et le passionné culinaire qui vient consommer ces streams pour en apprendre plus et débattre.
Je vais construire l’User Journey de mon second persona, à savoir le passionné culinaire. Il va pouvoir :
Maintenant qu’elle est construite dans les grandes lignes (vous n’avez pas besoin d’être le plus exhaustif possible ici, vous le serez par la suite), nous allons voir dans l’étape suivante comment les regrouper par thème pour poser les premières bases de votre Story Map !
En repartant de votre User Journey, vous allez pouvoir réunir les différentes actions de votre persona en “thème”. Ces thèmes ne sont d’ailleurs autres que les EPICS de votre produit. Vous en saurez plus ici sur le terme s’il ne vous est pas familier, mais il s’agit globalement de User Stories très macro.
Dans mon exemple précédent, je peux typiquement définir les EPICS suivantes :
Ces EPICS sont à écrire sur des post-its et à placer sur votre axe horizontal, celui de la “timeline”, qui représente le déroulé des actions de votre utilisateur dans le temps.
Pour le moment, celui-ci est très large en terme de scope, et c’est normal. Le but étant maintenant, sous chaque EPIC, de rentrer un peu plus dans le détail.
Nous allons donc rajouter de nouveaux post-it : les “Features”. Qui représentent les fonctionnalités macro à développer dans chaque EPIC.
Puis, sous ces features, nous allons maintenant pouvoir rajouter toutes les tâches - qui seront directement vos user stories - que cet utilisateur va pouvoir y faire !
Vous vous demandez sûrement pourquoi mes post-its “User Stories” sont répartis et séparés par des traits ? Nous y arrivons tout de suite dans la dernière étape !
Maintenant que nous avons nos thèmes, EPICS et premières user stories réparties sur notre tableau, nous allons pouvoir les prioriser !
Il est important que vous définissiez en premier votre MVP (Most Valuable Product), afin de déterminer quelles sont les features essentielles à son fonctionnement, celles dont vous ne pourrez certainement pas vous passer. De ce fait, il vous faudra mettre en plus basse priorité les features de “confort”, qui peuvent être un vrai plus mais qui n'empêchent pas votre produit de fonctionner.
Vous pouvez vous servir du dot voting pour déterminer tous ensemble, avec parties prenantes du produit, queles US (et donc fonctionnalités) seront prioritaires vis-à-vis des autres.
Vous arriverez donc à la suite de cette répartition à cela :
De cette manière, vous allez pouvoir laisser en place vos EPICS et Features comme ils sont, puis regrouper toutes vos user stories qui font parties de votre MVP. Tracez ensuite un trait sous ce premier regroupement. Félicitations, vous avez là la constitution de votre premier release !
Faites ensuite le même travail pour définir les éléments qui sont selon vous importants mais non essentiels pour définir une priorité 2. Et enfin les éléments qui ne sont que du confort et qui vont constituer une potentielle priorité 3.
Voici la représentation globale de mon Story Mapping, à laquelle vous avez également accès ici :
La Story Map n’a pas pour unique but de vous aider à lancer les développements de votre produit ou de votre nouvelle feature. N’hésitez pas à la garder vivante, à la mettre à jour, à rajouter ou enlever des éléments en fonction des directions que peuvent prendre les développements de votre produit.
C’est un excellent outil de suivi tout au long de vos développements qui va vous aider à avoir une représentation très visuelle de votre produit et à le recentrer sur l’essentiel quand vous en aurez besoin !
Auteur(s)
Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !
Notre équipe d'experts répond à toutes vos questions.
Nous contacterDécouvrez nos autres contenus dans le même thème
La qualité est un enjeu très important dans le développement logiciel, cet article vous permettra de (re)découvrir les impacts de la non-qualité, les bienfaits de la qualité et les bonnes pratiques qualité.
Aujourd’hui on parle de product management pour qualifier tout et n’importe quoi, ce qui entraîne la mise en place d’organisations produits sur des bases bancales. Quelles sont les principales erreurs commises ? Comment les éviter ? La liste n’est pas exhaustive mais vous permettra assurément de mieux appréhender votre méthodologie produit.
Cet article présente mes méthodes préférées pour bien appréhender un nouvel environnement de travail, incluant des outils pratiques comme le rapport d'étonnement, le Value Stream Mapping, le mandat de mission, la matrice des attendus et les Moving Motivators, afin de faciliter l'intégration, améliorer les processus et renforcer la collaboration au sein de l'équipe