On nous demande souvent comment démarrer un projet Agile. En effet, il est parfois difficile pour un product owner de se lancer et de structurer son backlog quand il est vide et que tout est à faire.
Si la mission du product owner est de maximiser la valeur du produit aux yeux des parties-prenantes, comment identifier ces parties-prenantes ? Et comment identifier ce qui leur apporte de la valeur ?
Une technique que j’ai découverte en parcourant le blog https://blog.myagilepartner.fr/ que j’ai toujours trouvé très instructif est celle de la User Story Map.
Cette méthode a pour vertu de répondre à ces deux questions, elle part de l’utilisateur, étudie son parcours et ses interactions pour aboutir à un backlog structuré et même déjà des ébauches de versions du produit.
Je l’ai utilisée lors d’une formation que je donnais et j’ai trouvé qu’elle était vraiment formidable. Pour toutes celles et ceux qui se trouveraient confrontés à un démarrage de projet, je vous invite donc à découvrir la user story mapping sans plus attendre !
Connaître ses utilisateurs
Avant toute chose, il faut apprendre à connaître ses utilisateurs. Et pour cela, il est utile de concevoir des fiches personae.
Un persona est un utilisateur-type, une représentation fictive des utilisateurs cibles. Souvent utilisé en marketing, c’est un outil très utile pour le product owner.
Outre la connaissance des utilisateurs, l’avantage pour le product owner est qu’il pourra utiliser le point de vue de ces personae pour écrire ses fameuses “user stories”.
Il existe un grand nombre d’outils en ligne pour construire ces fiches d’identité personae, mais globalement, il s’agit de lui trouver un titre, un âge, de décrire brièvement sa typologie d’utilisateur et d’étudier ses motivations, ses frustrations et de fait ses buts et comportements et ce que cela implique.
Voici un exemple de template :
Par exemple, dans le cas d’un projet d’application de matching professionnel, on aurait les personae suivants :
Le recruteur, le candidat et l’administrateur de l’application.
Pour le recruteur on peut imaginer une fiche persona telle que :
Bien sûr, il est possible de différencier les profils de recruteurs et d’avoir des personae différents selon les profils (chasseurs de tête, RH d’une grande entreprise, etc.), mais pour simplifier nous allons partir sur ces trois archétypes.
On voit qu’avec ce template on fait immédiatement ressortir ce qui a de la valeur pour l’utilisateur et qu’on peut d’ores et déjà voir émerger des idées d’innovation pour répondre à ses frustrations.
Il convient de répéter l’exercice pour chacun des personae identifié.
Étudier le parcours de l’utilisateur
En marketing encore une fois (je suis une product owner issue d’une formation marketing, mais vous verrez finalement que bien que le métier puisse sembler éloigné de cette formation, de nombreuses méthodes marketing s’avèrent très utiles dans mon métier), on parle souvent de “parcours client” ; en développement informatique nous parlerons plutôt de parcours utilisateur (ou user journey en anglais). En effet, l’utilisateur n’est pas nécessairement le client. On le voit ici avec le persona de l’administrateur de l’application dans mon exemple précédent.
Il s’agit d’étudier les comportements et les interactions que l’utilisateur va avoir avec notre futur produit. Par exemple si nous reprenons le persona de Louis et que l’on imagine ses interaction avec une application de matching professionnel :
Il s’agit ici d’un parcours simplifié puisqu’on pourrait imaginer encors beaucoup d’actions de la part de ce persona, comme par exemple “parcourir les candidats” pour faire du sourcing exploratoire, etc.
Une fois de plus, la description du parcours utilisateur est à faire pour chaque persona identifiée. Je ne vais pas pour cet exemple le faire pour chaque persona mais pour illustrer mes propos, voici tout de même celui du persona du candidat :
Chaque action correspond à une fonctionnalité du produit qui pourra être développée de manière itérative via les user stories.
Par exemple, pour la fonctionnalité “Créer une offre d’emploi”, on pourra avoir plusieurs phases et donc plusieurs user stories comme “En tant que recruteur, j’indique la description d’une offre d’emploi afin de la publier” / “En tant que recruteur, j’upload une offre d’emploi au format PDF afin de la publier”, etc.
Identifier les thématiques principales
C’est à cette étape que l’on va dégager les thèmes principaux, qui correspondront au niveau Épopée (ou Epic). En effet, si on regarde de plus près nos parcours utilisateurs, cela finit par sauter aux yeux.
Pour le recruteur :
Pour le candidat :
On voit notamment que certaines thématiques sont communes aux deux parcours utilisateurs.
Démarrer le story mapping
Nous pouvons désormais passer au story mapping à proprement parler. Pour ce faire, c’est très simple. Nous allons placer les épopées et les fonctionnalités sur une matrice qui croise le temps (puisque les actions utilisateur sont effectuées dans un ordre “logique”) et la priorité de disponibilité de ces actions dans l’application (notion qui permet outre la mise en évidence des dépendances, introduit également la notion de valeur).
Cela peut sembler curieux d’avoir mis la gestion des utilisateurs en dernier dans l’ordre des épopées, mais finalement l’application peut être utilisée sans cette couche applicative : dès lors qu’il y a des offres d’emplois et des CV de candidats. Il fait donc sens de la placer en dernier.
Ensuite, on place les fonctionnalités, que l’on développera itérativement via les user stories que l’on détaille juste en dessous (ici j’ai zoomé sur les deux premières épopées pour une meilleure lisibilité) :
Et nous voilà déjà avec une ébauche de backlog structuré et une vision du futur produit !
Si on prend soin de réordonner les stories par priorité, on peut même d’ores et déjà voir se dessiner des versions de release du produit :
En bleu, la première version avec le minimum de fonctionnalités requises pour fonctionner. En gris, ce qui pourrait correspondre à une v2 avec plus de détails et de profondeur sur les fonctionnalités basiques.
Et enfin, en vert, une v3 plus innovante avec la gestion d’automatismes : algorithmes, import PDF, partage vers d’autres plateformes, etc.
Gladys NIARFEIX, Lyon, le 31/05/2022