Prioriser un backlog sans perdre le cap

Votre backlog contient plus de cent tickets et tout le monde jure que le sien est prioritaire. Les libellés « urgent » se multiplient, mais rien ne sort en production depuis trois semaines parce que l'équipe saute d'un sujet à l'autre.

L'objectif de lancement, celui écrit dans le cadrage, n'est plus cité en réunion. On parle features, pas impact. C'est le signal que la priorisation a lâché le cap produit.

Autre symptôme : les revues de fin de sprint ressemblent à un inventaire de tâches cochées, sans lien avec une métrique. Beaucoup fait, peu de progrès mesurable.

Avant de trier des tickets, reformulez l'objectif mission en une métrique directrice : north star metric. Exemples : taux de conversion du formulaire de contact, délai moyen de publication d'une actualité, panier moyen sur mobile.

Chaque item du backlog doit répondre à une question : « Quelle hypothèse sur cette métrique teste-t-on ? » Si la réponse est « aucune, c'est une demande esthétique », classez-le en nice-to-have explicite.

Documentez trois hypothèses maximum pour le trimestre. Le backlog sert à les valider ou les invalider, pas à absorber toutes les idées de l'entreprise.

Trier : séparez bugs bloquants, dette technique critique et évolutions. Les bugs qui empêchent une conversion ou une obligation légale passent avant tout.

Estimer : pour chaque évolution, notez impact (1 à 5 sur la north star) et effort (1 à 5 en jours-personnes). Pas besoin de précision absolue : l'ordre de grandeur suffit pour arbitrer.

Arbitrer : placez en haut le quadrant fort impact / faible effort. Limitez le « en cours » à trois chantiers simultanés maximum pour une petite équipe. Le reste attend, visible dans le backlog, pas dans le sprint.

Revoir : toutes les deux semaines, quinze minutes avec le décideur. Question unique : « Qu'est-ce qu'on arrête ou repousse pour protéger l'objectif ? » Un refus documenté vaut mieux qu'un oui silencieux qui ne sera pas livré.

Fixez un sprint goal en une phrase liée à la métrique. « Livrer le tunnel de devis mobile » plutôt que « avancer sur le site ». En fin de sprint, on juge par rapport à ce goal, pas à la liste complète.

Gelez le périmètre du sprint une fois démarré. Les urgences réelles existent : traitez-les en échange. Quel item du sprint sacrifie-t-on ? Sinon, tout est urgent et rien ne l'est.

Communiquez le backlog visible aux parties prenantes (Notion, ClickUp, Jira, peu importe l'outil). La transparence réduit les relances et force les demandes à entrer dans le même tamis de priorisation.