Backlog VS release plan VS roadmap produit : C’est quoi la différence ?

Backlog, release plan, roadmap produit : trois outils super importants pour les product managers. Notre experte de la vulgarisation, Mamy Nintendo, nous explique les différences entre ces notions complémentaires, mais à ne pas confondre.

Le Ticket : “Salut Mamy, ça va ? Dis moi, tu pourrais m’expliquer les différences entre un backlog, un release plan et une roadmap produit ?”

Mamy Nintendo (concentrée sur sa partie de Mario Kart) :  “…Ah le salaud de Luigi, il m’a défoncée avec sa banane…” (repose sa manette) “Mais bien sûr, mon petit. Assieds-toi, je vais t’expliquer…”

Définition – Le backlog produit, c’est quoi?

Le backlog produit (ou carnet de produit en français, mais ça, personne ne le dit en vrai) est une liste priorisée de fonctionnalités à faire pour construire ou développer un produit. En gros, c’est tout le boulot qui attend l’équipe.

Sache, pour la théorie, que c’est un outil central de la méthodologie Scrum. Et que la / le Product Owner (PO) en est la / le responsable. Comme un videur de boîte, c’est la / le PO qui va dire aux parties prenantes qui viennent avec des idées de fonctionnalités : “Toi, tu rentres. Toi, t’as des baskets, t’es pas prio, tu rentres pas”.

On distingue le backlog produit du Sprint backlog (ou carnet de sprint, mais là encore, expression inusitée). Le premier, c’est l’ensemble des fonctionnalités d’un produit à construire. Le deuxième, c’est l’ensemble des tâches à effectuer durant un sprint. Au lieu de te démoraliser à te dire qu’il te reste tout ça à faire, tu découpes ton projet en plus petits bouts. Et tu gardes la foi.

On retrouve généralement dans le backlog produit des User Stories (ou récit utilisateur = description d’un besoin utilisateur).

Pour résumer, un backlog produit, c’est un outil :

• de collecte. C’est le lieu où toutes les fonctionnalités sont rassemblées (afin d’éviter de perdre des idées en route).

• de centralisation. Il n’y a qu’un backlog pour toute la vie d’un produit.

• de planification. Comme les tâches y sont priorisées en fonction de leur importance dans le produit / leur durée de développement, on sait dans quel ordre et quand on doit les traiter.

• de communication. Le backlog produit doit être visible par tout le monde (même s’il est destiné, en soi, à l’équipe produit et tech) ! La plupart du temps grâce à un tableau physique ou en ligne (cf JIRA, Trello, Asana, Notion etc.)

• Vivant. Un backlog produit est évolutif et surtout pas figé. On peut y ajouter, supprimer, modifier des éléments tout au long du développement du produit. A la différence d’un cahier des charges (#CultureProjet).

Définition – Le release plan (ou plan de release), c’est quoi ?

Alors, lui, c’est le grand oublié du produit. Le p’tit silencieux au fond de la classe, écrasé entre ses plus bruyants petits copains backlog et roadmap. Et pour cause, il peut être très utile, mais reste une pratique facultative et en dehors de Scrum.

Le plan de release correspond à un sous-ensemble de fonctionnalités du backlog produit qui doivent être développées sur l’ensemble des sprints d’une période définie (= la release). 

Ce qui revient à dire que, pour faire un plan de release, il faut :

• Déjà un backlog… donc une roadmap (pour savoir ce qu’il y a concrètement à faire)

• Et définir un objectif et/ou une durée / date de fin de la release (ex : quand un sous-ensemble du backlog est vide, quand un produit partiel a été développé, quand le budget est consommé, en fixant une date précise etc.)

En gros, c’est pour avoir un niveau de pilotage intermédiaire entre la roadmap, dont on va parler après, et le sprint (dont on vient de parler).

Pour donner de la visibilité sur un peu plus que quelques semaines. Et mieux mesurer la vélocité d’une équipe. Un entre-deux entre adaptation et anticipation, en somme.

Définition – La roadmap produit, c’est quoi?

Alors, elle, c’est l’inverse du plan de release dans la classe. C’est la star. Celle dont les PM parlent sans cesse (même quand il s’agit parfois de plan de release…)

Une fois n’est pas coutume, la traduction en français est tout aussi explicite pour définir ce qu’est une roadmap produit : une feuille de route produit !

On va citer Marty -Dieu- Cagan pour la définition d’une roadmap produit : “C’est l’itinéraire entre là où se trouve votre produit actuellement et votre vision produit”.

Rappelons ici que la vision produit est une description du futur que vous essayez de créer. C’est en quelque sorte le contexte dans lequel vient s’inscrire la roadmap produit. 

Cette dernière doit donc refléter simplement mais stratégiquement vos objectifs principaux : développer le produit à l’international ? Lancer le produit sur mobile ? Adresser le produit à d’autres cibles de personnes utilisatrices ? Etc.

A noter qu’elle n’est pas propre au produit. On peut avoir des roadmaps stratégiques, des roadmaps commerciales, des roadmaps com’, des roadmaps marketing…

Voici un petit résumé imagé de ces 3 notions complémentaires :

	Si c’était une question…	Si c’était un concept…	Si c’était un emoji…	Si c’était une course à pied…
Roadmap produit	Pourquoi ?	Stratégie	🧭	Endurance (~ année)
Release plan	Quoi ?	Plan de fonctionnalités	👣	Demi-fond (~ mois)
Backlog produit	Comment ?	Liste de fonctionnalités	🔨	Sprint (~ semaines)

Pourquoi backlog, plan de release et roadmap produit sont imbriqués ?

Pour vulgariser, on a affaire à trois différents niveaux de zoom (macro, micro et moléculaire). Avec des personnes à qui cela s’adresse et des objectifs associés différents.

Avec la roadmap produit, on est sur un outil discuté au niveau exécutif de la boîte pour organiser et communiquer ses objectifs produits stratégiques et la direction que l’on va prendre dans les prochains mois (voire année(s)). Sans oublier les raisons derrière ces choix (opportunité du marché, demande des utilisateurs, pression concurrentielle etc.).  

Souvent, on confond cette roadmap produit avec une to-do list, soit… le plan de release ! Autrement dit, on mélange le “quoi ?” et le “pourquoi ?”

C’est parce qu’une roadmap, en soi, ne peut suffire. Il faut en effet traduire la stratégie en un plan actionnable (avec des fonctionnalités, des améliorations, des correctifs…) pour les équipes. Passer des grandes idées aux plus petits projets sur lesquels les équipes vont pouvoir travailler concrètement. C’est là où intervient donc le plan de release.

Mais sans backlog produit, pas de plan de release possible ! (difficile de faire un plan de fonctionnalités sans… liste de fonctionnalités au préalable, hein ?)

Donc en gros, pas de roadmap, pas de backlog produit (ou alors un produit qui avance comme un poulet sans tête). Pas de backlog produit, pas de plan de release. Pas de palais… pas de palais.

---

– Le Ticket : “Ah OK… C’est déjà bien plus clair maintenant. Merci Mamy !”

– Mamy Nintendo : “De rien mon p’tit” (retourne à sa partie) “Bon, allez, revanche Luigi…”

---

Comment ?! Vous n’êtes pas encore abonné(e) au Ticket ?

Corrigeons tout de suite cela 👇