Idée principale

Roadmap et backlog se ressemblent parce que les deux contiennent des sujets et que les deux sont ordonnés. Ils ne répondent pas à la même question. La roadmap sélectionne : quels grands sujets méritent l'attention de l'entreprise à cet horizon. Le backlog organise : comment se découpe le travail sur les sujets déjà sélectionnés.

La granularité le rend visible. « Automatiser la saisie des documents papier » est une initiative de roadmap ; dans le backlog, elle devient des problèmes, des fonctionnalités, des tâches techniques, des tickets de design, des critères d'acceptation, des dépendances, des tests, des itérations. Le backlog est plus fin parce qu'il est opérationnel : il sert à produire. La roadmap est plus grossière parce qu'elle sert à aligner.

Deux objets, deux fonctions, et deux publics : on ne lit pas une roadmap pour savoir quoi faire demain matin, on ne lit pas un backlog pour comprendre où va le produit.

Pourquoi c'est important

Cela empêche la confusion la plus coûteuse des deux : traiter la roadmap comme une base de données produit, où l'on finirait par ranger tout ce que l'entreprise pourrait faire. Une roadmap qui descend au niveau de la tâche perd sa fonction d'alignement sans gagner celle de production.

Cela donne aussi la bonne direction de lecture : un sujet passe de la sélection au découpage, jamais l'inverse. Un backlog ne remonte pas naturellement vers une direction.

Nuances et limites

La frontière n'est pas toujours nette pour les petits sujets, qui entrent directement au niveau du découpage sans avoir jamais eu de carte de sélection — et c'est légitime.

Et la séparation des deux objets suppose qu'ils soient tenus par les mêmes personnes, ou au moins qu'elles se parlent : deux outils séparés confiés à deux fonctions différentes produisent deux priorisations qui divergent.

Questions ouvertes

• À quelle taille un sujet cesse-t-il de mériter une carte de sélection pour entrer directement dans le découpage ?