Roadmap produit (feuille de route Agile) : Définition et bonnes pratiques

La roadmap produit est un document graphique qu'utilise le product owner dans le but de simplifier la communication de la direction stratégique du projet.

Son objectif est de synchroniser l’ensemble des parties prenantes sur les objectifs à atteindre pour le succès du projet.

Dans cet article, nous verrons comment se servir d'une feuille de route agile, comment la mettre en place, et enfin comment la présenter.

La Roadmap Produit : Définition

Dans le domaine du développement de produits, les méthodes agiles utilisent une représentation visuelle de la stratégie à long terme. 

C'est la Roadmap produit.

Elle est utilisée pour aider les équipes de développement à communiquer leur vision et leur stratégie pour le produit à toutes les parties prenantes, y compris les clients, les utilisateurs et les parties prenantes internes.  

Dans le cadre du framework SAFe, la roadmap product est utilisée pour aligner les différentes équipes de développement et de livraison de produits sur une vision commune du produit.

Elle sert également de guide pour la planification de produit et permet aux équipes de rester concentrées sur les objectifs à long terme, tout en effectuant des itérations courtes pour répondre aux besoins des clients.

Pourquoi faire une Roadmap Produit ? 

La feuille de route agile est utile pour les principales raisons suivantes :

1) Donner les grandes directions au projet

Bien que la roadmap agile ne soit pas indispensable, elle permet cependant de favoriser des idées de développement en amont de la phase de réalisation.

Cela engendre un potentiel d'anticipation.

L’équipe doit pouvoir se servir de cette roadmap comme une base de données d’idées.

Elle est souvent exigée par les fonctions rh.

Ainsi, elle sert à conduire le projet, à donner les grandes directions et bien entendu de la visibilité sur les grandes étapes.

Malgré tout, il faut garder en tête que la feuille de route reste une direction et non un objectif ferme à atteindre.

En effet, si on prévoit tout et qu’on la respecte à la lettre, l’équipe agile mènera finalement le projet en mode prédictif.  

roadmap produit agile

Modèle de la Roadmap Produit

Visualisez l'évolution de votre produit

2) Enrichir le backlog 

Effectuer une roadmap product permet d’avoir les objectifs dans les grandes lignes.

Cela aidera le product owner à construire le product backlog.

Avec le client, il va creuser les solutions que ce dernier pourrait avoir en tête.

Il va ensuite orienter ses questions sur les besoins qui ont fait émerger cette solution éventuelle.  

Petit à petit, il va remonter le fil de l’eau pour comprendre les causes de chaque problématique afin de résoudre le problème racine.  

Toutes ces précieuses informations seront compilées et priorisées dans le product backlog. 

Product Backlog VS Roadmap

La roadmap produit est une sorte d’incrément de la stratégie. Elle se doit d’évoluer au même titre que le product backlog.  

Elle reste vivante !

Comme pour le Product Backlog (carnet des besoins), on va venir sélectionner de la roadmap product les besoins à réaliser en priorisant l’ordre de réalisation.

Les actions entreprises doivent toujours être celles qui apportent le plus de valeur ajoutée au projet. 

Ainsi, la feuille de route agile vient compléter le Product Backlog en donnant une vision macro du projet. Son but est de se projeter des prévisions pour donner une vision globale.

roadmap et backlog

Cependant, plus les prévisions sont éloignées, moins elles sont précises.  

Pourquoi donner de la prévision dans un projet agile ?  

Se projeter va permettre à l’équipe de s’organiser en conséquence, de clarifier les objectifs, de s’aligner avec les parties prenantes.

En bref, de s’assurer que tout le monde est bien au clair avec la direction prise.

La première version de la roadmap de projet agile permettra également d'ajuster le nombre de personnes et de compléter les compétences nécessaires pour le projet.

Comment construire une Roadmap Produit efficace ?  

Une feuille de route réussie passe par un tableau bien souvent nommé “the go product roadmap”.

Pour la remplir, il faut rester synthétique (n’oubliez pas que l’on est en macro) .

1) Création de la Roadmap

Voici ses 4 étapes de construction : 

  1. Donner la vision produit :   Le produit s’adresse-t-il à sa “cible client” : Qu’est-ce que les utilisateurs recherchent ? Quel est le problème à résoudre ? En quoi cette problématique sera résolue ? Quel est son avantage concurrentiel ? 
  2. Établir des objectifs : Pour atteindre la vision produit préalablement définie 
  3. Donner des estimations temporelles : Pour des missions courantes, à court terme ou pour le futur
  4. Donner les résultats envisagés avec la feuille de route : Définir les objectifs en fonction des horizons temporels

2) Maintenir la roadmap flexible

Une fois établie, la feuille de route doit rester flexible.

Dans ce contexte agile, la collaboration entre le Product Owner et le Product Manager prend toute son importance :

  • Le Responsable Produit "PM", avec sa vision stratégique, s'assure que la direction prise est en accord avec les tendances du marché et les objectifs à long terme.
  • Le PO, concentré sur les aspects tactiques, veille à ce que la feuille de route réponde aux besoins immédiats des utilisateurs et qu'elle serve de guide flexible, plutôt que de contrat rigide à suivre à la lettre. 

Si les parties prenantes souhaitent que l’équipe suive la feuille de route “agile” à 100%, il faudra expliquer en quoi cela dénature le projet et le mets en péril.

A commencer par les retours précieux obtenus lors des démos !

En agilité, on cherche à co-construire au fur et à mesure du temps le projet avec le client.

Il est donc primordial d'innover.

Or, avec la roadmap produit, si elle est suivie dans son entièreté, l’innovation n’a plus sa place tant le projet est cadré.  

Ainsi, la feuille de route ne peut pas être une promesse.

Si ce n’est pas le meilleur plan à suivre, il ne faut pas hésiter à l’abandonner pour la réussite du projet.  

Zone d’efforts : qu’est-ce que c’est et à quoi ça sert ? 

Une zone d'efforts va être le taux de complexité qui va être attribué à une tâche.

Cela va se faire via un baromètre allant de 1 à 10.

1 étant une valeur qui demande le moins d'implication et 10 étant la valeur qui demande le plus d'efforts à l'équipe pour la réalisation de cette tâche. 

En estimant ces zones d’efforts, l’équipe devra garder en tête les objectifs à atteindre et non les actions à réaliser.

La vision doit rester la plus ouverte possible et non pas étriquée.  

Connaître les objectifs à atteindre permettra de réfléchir à plusieurs possibilités d'action afin de les combler.

Au fur et à mesure du temps, les développeurs vont trouver les solutions les plus pertinentes pour répondre à l'objectif tout en étant dans une suite logique par rapport aux missions réalisées précédemment.  

Exemple

Le product owner ne doit pas avoir comme objectif de faire une nouvelle page d'accueil, mais plutôt de convertir plus de visiteurs. 

Besoin Convertir plus de visiteurs

Problème : Manque de visibilité

Solution : Développer un nouveau site web et/ou développer les réseaux sociaux et/ou rendre le bouton d’inscription plus imposant et/ou organiser un évènement.

Selon les retours utilisateurs, la solution retenue ne sera pas forcément la première envisagée.

Ils pourraient aussi faire en sorte que les champs du formulaire d'inscription soient moins importants pour éviter la non-inscription d'une personne qui est découragée ou bien qui ne veut pas donner certaines informations. 

Ainsi, l’équipe ne s’engagera pas trop tôt dans une réalisation et la roadmap restera agile.

Comment présenter (pitcher) la Roadmap Produit ?

Voici quelques bonnes pratiques à suivre pour présenter votre roadmap agile :

1. Le pitch

Limitez-vous à l'essentiel : Vous disposez d'un court laps de temps pour transmettre les informations cruciales. En fait, la concentration maximale du cerveau humain ne dure que 10 minutes.

Structurez vos messages clés : Préparez en avance vos points principaux et organisez-les de manière cohérente.

Envisagez votre introduction : Ces premières minutes qui retiendront vos interlocuteurs. Si vous démarrez bien, vous serez positivement lancé.

Préparez votre conclusion : Quels sont ces messages avec lesquels vos interlocuteurs devront repartir ?

2. La présentation

Pour appuyer votre intervention, préparez une présentation légère, aérée et agréable :

Présentez chacun des objectifs à atteindre ainsi que les résultats clés attendus dans le trimestre à venir (Bonjour les objectifs SMART)

Passez ensuite au product backlog dans le trimestre à venir pour affiner les besoins à résoudre

Enfin, reprenez de la hauteur avec une vision plus globale reprenant passé/présent/futur.

Évidemment, tout cela doit répondre sur le long terme à la vision produit qui a été décrétée lors de l’élaboration de la “Go Product Roadmap”. 

Attention :

Gardez en tête que la collecte des besoins/idées sera prolifique.

Toutefois, l’idée n’est pas de la suivre à 100 %, mais bien d’identifier ce qui aura le plus de valeur pour les utilisateurs.

Bien souvent, dans ce cas, l’équipe se met une grosse pression pour concrétiser toutes les idées (en plus de tous les changements qui surviennent) :

  • La masse de travail devient considérable
  • La cadence s’accélère
  • Le rythme n’est plus soutenable

Cela aboutira inévitablement à une baisse de la qualité de la réalisation du projet.

L'équipe sortira ainsi des principes agiles, compromettant à la fois le rythme durable et l'excellence continue.

Conclusion

La roadmap produit agile sert à avoir une vision globale.

  • Elle est conforme aux attentes des collaborateurs qui ont un regard sur le projet tout en étant à l’extérieur de ce dernier. 
  • Elle permet aussi au product owner d’avoir une vision stratégique générale pour construire un product backlog plus simplement répondant rapidement aux grandes lignes du projet. 

Les idées évoquées étant nombreuses dans la feuille de route agile, l’équipe de développement peut piocher à tout moment une idée pour la développer.

Mais uniquement si cela lui parait pertinent au cours du projet.  

La feuille de route agile n’est pas figée, elle évolue en même temps que le projet se déroule.  

N’oubliez pas que plus on cadrera le projet, plus on perdra cette notion d’innovation et on rentrera dans du prédictif !

tous nos outils et guides pratiques

AUDREY DEGUARA

A propos de l'auteur

Impliquée dans l’univers du projet depuis son Master Spécialisé au Canada en 2003, Audrey accompagne les projets en guidant les chefs de projet et les product owners/ scrum masters à tirer le meilleur des équipes projet.

Passionnée par le projet et l’Humain, elle s’est investie dans divers secteurs d’activité. Toutes ses expériences ont comme fil rouge l’accompagnement autour de ce sujet.
En savoir plus sur Audrey et ses publications

Les autres articles du dossier 

{"email":"Adresse email invalide","url":"Url du site invalide","required":"Champ obligatoire non renseigné"}

Télécharger le Guide du

Chef de Projet

25 Conseils d'expert en Management de Projet

Guide du Chef de Projet
Guide du Chef de Projet
>