Comment Structurer un Backlog Quand Plusieurs Projets Tournent en Parallèle

Une équipe qui fait avancer plusieurs projets en parallèle rencontre presque toujours le même problème : le backlog devient un fourre-tout où les éléments de projets différents se mélangent, et où personne ne sait plus, sans ouvrir chaque ticket, à quel projet il appartient et quelle est sa priorité relative.

Le symptôme : un backlog plat ne scalable pas

Un backlog organisé comme une liste plate fonctionne pour un seul projet, avec une seule équipe, sur une durée courte. Dès qu’un deuxième projet démarre en parallèle, cette structure plate ne suffit plus. Le tri par priorité devient ambigu : la priorité d’un élément du projet A n’a pas de sens comparée directement à celle du projet B, ce sont deux contextes différents.

Le résultat visible : des réunions de priorisation qui s’éternisent, parce qu’on essaie de comparer des choses qui ne sont pas comparables sur le même axe.

Trois niveaux, pas un seul

La structure qui fonctionne sépare trois niveaux distincts, plutôt que de tout aplatir dans un seul backlog.

Le niveau projet, pour la vision à long terme. Un project donne une vue roadmap de ce qui est prévu sur plusieurs trimestres, sans engager sur le détail d’exécution. C’est le niveau où on répond à « qu’est-ce qui est dans les cartons pour cette initiative, dans les six prochains mois ».

Le niveau release, pour ce qui doit sortir. Une release regroupe les capabilities qui doivent être livrées ensemble, indépendamment du projet d’origine. Une release peut très bien contenir des capabilities issues de deux projets différents si elles sortent en même temps.

Le niveau cycle, pour le travail réel de l’équipe. Un cycle contient les issues que l’équipe s’engage à traiter sur une période courte, tirées des capabilities prioritaires du moment, quel que soit leur projet d’origine.

Pourquoi cette séparation évite le mélange

Cette structure à trois niveaux évite la confusion parce qu’elle répond à des questions différentes à des moments différents. Un stakeholder qui demande « où en est le projet X » consulte le niveau project. Une équipe qui planifie son travail de la semaine consulte le cycle. Personne n’a besoin de comparer directement des éléments de projets différents au même niveau de détail.

La priorisation devient un arbitrage explicite, pas implicite

Sans cette structure, la priorisation entre projets se fait de façon implicite : celui qui crie le plus fort, ou celui dont le ticket a été créé en dernier, avance. Avec une séparation claire entre projects, releases et cycles, l’arbitrage devient explicite : au moment de composer un cycle, l’équipe choisit consciemment quelles capabilities, de quels projets, entrent dans la période à venir. La décision est visible, documentée, et peut être expliquée à n’importe quel stakeholder.

Ce que ça change au quotidien

Une équipe qui adopte cette structure ne travaille pas plus vite du jour au lendemain. Ce qui change, c’est la capacité à répondre immédiatement à « pourquoi ce projet n’avance pas cette semaine » sans devoir fouiller dans un backlog plat de plusieurs centaines d’éléments. La clarté de la structure remplace la mémoire individuelle de qui a décidé quoi.