Comment prioriser son projet avec une story map ?

Lorsque je commence un projet ou réponds à un appel d’offres, la lecture du cahier des charges est une activité à récompense variable. Trop léger, je crains que le client ne se lance tête baissée dans un projet aux contours flous ; trop rempli, je crains que la description du besoin soit figée.

Dans les deux cas, le format écrit peut donner lieu à des interprétations différentes et apporter plus de questions que de réponses. La communication finit par ressembler à une partie géante de Gartic phone, le jeu favori des Troopers pendant le Covid.

Cet écart est la raison pour laquelle je propose systématiquement de commencer la phase de cadrage par la création d’une story map.

Qu’est-ce qu’une story map?

Une story map est tout simplement la carte des besoins utilisateurs. C’est aussi le livrable de l’atelier de story mapping qui est une méthode de description des besoins utilisateurs de manière visuelle, chronologique et priorisée. Concrètement la story map est un tableau géant de post-it qui permet de comprendre d’un coup d'œil ce que fait un utilisateur dans l’outil qu’elle décrit.

Comment faire une story map ?

La story map ressemble à une pièce de théâtre :

• les personnages sont appelés personas ;
• ils vivent des aventures que l’on appelle des récits utilisateurs ;
• ces récits sont regroupés dans des chapitres, appelés epics ;

Les chapitres ou récits ont lieu dans des décors, vous l’avez deviné ce sont les interfaces du logiciel et elles ne sont pas visibles en tant que tel dans la story map.

Prenons une pièce de théâtre dont vous êtes le héros quotidien : se préparer le matin. Voici les epics :

• se lever ;
• se laver ;
• s’habiller ;
• manger.

Les récits utilisateurs possibles pour “se lever” sont :

• éteindre son réveil ;
• faire son lit ;
• ouvrir les volets ;
• faire quelques étirements.

Avantages du story mapping

Aligner les participants d’un projet sur une vision

Lors des ateliers de story mapping que j’ai pu animer, j’ai toujours constaté qu’il y avait plusieurs livrables. Le premier est bien sûr la story map, mais le second est plus surprenant.

Lorsque plusieurs personnes se mobilisent quelques heures pour imaginer leur futur outil, cela fait émerger toutes les incompréhensions et angles morts du début de projet. Mieux vaut que ces discussions aient lieu le plus tôt possible, et surtout avant la livraison ! Le format de l’atelier aide beaucoup et facilite les arbitrages avec la phase de priorisation.

Le choix des participants est donc primordial et c’est pour cela que j’insiste toujours pour faire venir de futurs utilisateurs, ou des personnes a priori non concernées comme le personnel administratif de l’entreprise.

Communiquer facilement sur un projet complexe

Le second avantage d’une story map est sa lisibilité. Le format de rédaction d’un récit utilisateur est compréhensible et exprime à la fois la solution et le besoin.

• En tant que Troopers, je mange un fruit afin d’avoir de l’énergie.

Exemple plus réaliste :

• En tant que comptable, j’exporte la facture afin de la partager au client.

Alors qu’un cahier des charges se lit, une story map se consulte et se discute. Cette discussion fait émerger de nouveaux post-it qui viennent alimenter la story map.

Au contraire, dans un cahier des charges, des synonymes ou des formulations peuvent créer des incompréhensions qui se révéleront désastreuses pour le projet. Cette phrase résume bien ma pensée : “Il nous arrive de considérer que tout ce que nous écrivons est clair et limpide. C’est parfois vrai et souvent faux.*”

Prioriser son projet avec le story mapping

Lors de la création de la story map, différentes solutions émergent pour un même besoin. Pour reprendre l’exemple de votre début de journée, pour l’epic “manger” certains vont passer une demi-heure à table tandis que d’autres se contentent d’un fruit. Mais si vous savez déjà que vous êtes en retard pour aller au travail, vous allez sûrement vous contenter d'un pain au chocolat fruit !

L’option “fruit” devient une V1 (version 1) et “petit-déjeuner complet” une V2. Le petit déjeuner V2 sera possible une fois que la V1 est sécurisée et s’il reste du temps après que toutes les autres epics de la V1 soient finies.

Nous utilisons la même logique pour créer un logiciel : prioriser la version qui répond au besoin en prenant le moins de temps possible. Une fois que cette priorisation a eu lieu vient l’estimation. L’une des grandes lois du développement logiciel est “qu'il y a toujours plus à créer qu'il n'y a de personnes disponibles, de temps et d'argent à y consacrer.” Je fais donc estimer par l’équipe de développement la V1 de la story map.

Une fois le résultat obtenu, je sais si le budget est suffisant pour livrer toute la V1, si c’est le cas alors certains récits ou epics relégués en V2 pourront être conçus.

Et l’éco-conception dans tout ça ?

Le story mapping est un très bon allié pour réduire l'impact environnemental de son projet. Le référentiel général d’écoconception des services numériques (RGESN) préconise en effet de :

• définir les cibles utilisatrices (critère 1.2) ;
• leurs besoins et attentes réelles (1.3) ;
• et d’optimiser leurs parcours (4.4).

Pas de problème ! La conception d'une story map nécessite toutes ces actions, notamment l’optimisation du parcours utilisateur, pour lequel on livre une V1 avant d’ajouter des fonctionnalités de confort.

Inconvénients du story mapping

La story map et les sujets techniques

Parfois, un système ou une fonctionnalité doit être créée sans qu’elle n’ait aucune interface utilisateur. C’est le cas d’un algorithme de rapprochement de candidats et d’offres d’emploi ou un mécanisme de génération de commandes.

Dans ces cas-là, je trouve que la story map est plus difficile à manier. Je finis généralement par créer un post-it recensant le fonctionnement complet. La réalité est que l'approche agile trouve ses limites dans ce cas. Un système qui n’est codé que sur la base de besoins exprimés manque un peu de vision. Il faut aller plus loin en anticipant tous les cas possibles et en s’inspirant de solutions existantes.

Estimation et budget

La story map est en revanche plus dure à estimer aussi finement qu’un cahier des charges car la description des besoins est moins fine. Les récits utilisateurs sont en effet complètement décrits au fur et à mesure du projet alors que dans un cahier des charges le fonctionnement est figé avant le début du développement.

Faut-il faire un cahier des charges ou une story map ? Pour une prestation au forfait, elle garde sa pertinence pour aligner les parties prenantes, éviter les découvertes en cours de projet et faciliter le suivi du développement. Pour les produits gérés en agilité, j’organise des ateliers d’Extreme Quotation pour obtenir des estimations et répartir l’effort sur le planning.

Si une story map est simple à comprendre, en créer une demande un peu d’expérience et je conseille de faire appel à une personne expérimentée pour l’animer. Cet atelier fait souvent émerger des visions contradictoires et un facilitateur externe aidera à faire de cet atelier une pierre fondatrice du produit.

*Culture produit, Octo, Samuel Retière - Xaviera Meyer Bosque - Benoit Ricaud