Backlog plein, roadmap bloquée : le vrai problème de priorisation

Votre roadmap est pleine. Votre backlog déborde. Vos devs sont occupés. Et pourtant, rien de ce qui compte vraiment n'avance.

Ce n'est pas un problème de productivité. C'est un problème de priorisation déguisé en activité.

J'arrive dans une startup, je regarde le board. 60 tickets en cours, 3 sprints de retard, une équipe qui court. Et quand je demande "c'est quoi votre priorité numéro 1 cette semaine ?", j'ai 4 réponses différentes selon à qui je pose la question.

C'est là que tout se joue.

L'activité est rassurante, la priorité est inconfortable

Un backlog qui se remplit donne l'impression qu'on avance. Des tickets créés, des tickets déplacés, des commits qui s'accumulent : tous les signaux visibles disent que l'équipe travaille.

Décider que 80% de ce backlog ne sera jamais fait, ça, c'est une conversation difficile que personne ne veut avoir. Elle implique de dire non à un client, de renoncer à une feature qu'un investisseur a mentionnée en passant, d'admettre qu'une idée qui semblait bonne il y a six mois ne l'est plus.

Alors on évite la conversation. On continue de coder ce qui est en haut de la liste, pas ce qui crée de la valeur. Le backlog devient un entrepôt où on range les décisions qu'on refuse de prendre.

Product et tech ne parlent pas le même langage de priorité

Le product veut des features. La tech veut de la stabilité. Sans quelqu'un pour faire le lien entre les deux, chaque camp priorise dans son coin.

Le product empile les demandes utilisateurs et les paris business. La tech empile la dette technique, les migrations reportées, les correctifs de sécurité qui attendent leur tour. Chacun a de bonnes raisons. Chacun défend sa liste avec des arguments solides.

Le résultat, c'est une roadmap qui satisfait tout le monde sur le papier et personne en prod. Le trimestre se termine avec des features à moitié livrées, une dette technique qui a continué de grossir, et une équipe qui a l'impression d'avoir beaucoup travaillé sans que rien n'ait vraiment changé.

"Tout est urgent" veut dire que rien ne l'est

Quand tout est priorité haute dans Jira, la notion de priorité n'existe plus. C'est un symptôme, pas un accident : celui d'une équipe qui n'a pas encore eu la conversation difficile sur ce qu'elle est prête à ne pas faire.

Un board où chaque ticket est marqué "urgent" ne donne aucune information sur ce qu'il faut faire en premier. Il donne juste une excuse pour ne jamais avoir à choisir. La priorisation, par définition, suppose qu'on accepte de perdre quelque chose pour gagner autre chose. Sans ce renoncement explicite, il ne reste que de l'activité répartie au hasard.

Le symptôme visible : quatre réponses différentes à la même question

C'est le test le plus rapide pour diagnostiquer une équipe qui court sans avancer : demander à quatre personnes différentes - product, tech lead, dev, fondateur - quelle est la priorité numéro un de la semaine.

Si les quatre réponses convergent, l'équipe a un cap clair, même si l'exécution est imparfaite. Si les quatre réponses divergent, le problème n'est pas dans le backlog. Il est dans l'absence d'un alignement partagé sur ce qui compte, et cet alignement manquant coûte bien plus cher qu'un sprint de retard.

Ce que je fais en arrivant dans une équipe

Que ce soit en mission courte d'audit ou en accompagnement long, la première semaine n'est pas consacrée au code. Elle est consacrée à aligner tout le monde sur une seule question : qu'est-ce qu'on arrête de faire pour avancer sur ce qui compte vraiment ?

Concrètement, ça passe par :

1. Cartographier ce qui est réellement en cours - pas ce qui est dans le backlog, ce qui mobilise du temps de développeur cette semaine.
2. Confronter les priorités de chaque camp - product, tech, direction - dans la même pièce, jusqu'à ce qu'un arbitrage explicite soit posé.
3. Nommer ce qu'on arrête - la partie inconfortable, mais celle qui libère réellement de la capacité d'exécution.
4. Réduire le nombre de priorités simultanées à une poignée - assez peu pour que tout le monde s'en souvienne sans consulter un board.

C'est souvent la conversation la plus productive qu'une équipe n'a jamais eue. Pas parce qu'elle révèle une vérité cachée, mais parce qu'elle force à trancher ce que tout le monde savait déjà sans jamais l'avoir dit à voix haute.

FAQ : priorisation produit et backlog qui n'avance pas

Pourquoi une équipe qui travaille beaucoup n'avance-t-elle pas sur ce qui compte ?

Parce que l'activité et la priorisation sont deux choses distinctes. Une équipe peut être à 100% de sa capacité tout en travaillant sur des tâches qui ne créent pas de valeur, faute d'un arbitrage clair sur ce qui doit passer en premier.

Comment savoir si mon équipe a un vrai problème de priorisation ?

Demandez à plusieurs personnes de l'équipe - product, tech, direction - quelle est la priorité numéro un du moment. Si les réponses divergent, le problème n'est pas l'exécution, c'est l'absence d'alignement partagé.

Faut-il un product manager pour résoudre ce problème ?

Pas nécessairement un rôle dédié, mais quelqu'un doit faire le lien entre les priorités product et les contraintes tech, avec la légitimité pour trancher. Dans une startup sans CTO interne, ce rôle de liaison manque souvent, et c'est là que les deux camps priorisent chacun dans leur coin.

Comment réduire un backlog qui déborde sans frustrer l'équipe ou les clients ?

En rendant explicite ce qui a été décidé de ne pas faire, plutôt qu'en laissant les tickets s'accumuler indéfiniment. Un backlog trié et assumé, même court, vaut mieux qu'un backlog exhaustif que personne ne consulte plus pour décider quoi faire ensuite.

Ce que je recommande, en tant que CTO hands-on

Je vois cette situation dans quasiment chaque équipe où j'interviens : ce n'est presque jamais un manque de talent ou d'effort qui bloque la roadmap, c'est l'absence d'un arbitrage assumé entre product et tech.

C'est exactement le rôle que je joue en mission CTO hands-on auprès de startups pré-seed et seed : pas un audit qui pointe le problème et repart, mais une présence opérationnelle qui structure la priorisation avec l'équipe, code à ses côtés, et reste responsable des arbitrages dans la durée - que ce soit sur une mission courte de structuration initiale ou un accompagnement long.

Un backlog plein n'a jamais livré un produit. Une équipe alignée sur une priorité claire, si.