Quand le backlog mentait : la leçon d'une équipe matérielle sur l'ordonnancement par la valeur
Au printemps 2021, une équipe produit que j'appellerai le groupe Northgate retrouvait son élan après une année difficile. La moitié de l'équipe était en télétravail, un fournisseur clé annonçait encore des délais de douze semaines pour une carte de commande, et le propriétaire de produit gérait un backlog de 140 éléments. Sur papier, ils faisaient du Scrum. En pratique, l'ordre de ce backlog tenait du hasard : celui qui avait déposé une demande le plus récemment, ou plaidé le plus fort à la dernière revue, se retrouvait en tête.
Le Guide Scrum est sans détour à ce sujet. Le Backlog de produit est une liste ordonnée, et le Propriétaire de produit est responsable de cet ordre. Ordonné ne veut pas dire trié par date, par effort, ni selon qui crie le plus. Cela signifie séquencé pour que le travail le plus susceptible de livrer de la valeur vienne en premier. Northgate avait sauté cette discipline, et cela leur coûtait des sprints.
Comment le désordre se manifestait
Les symptômes étaient connus. Les sprints se terminaient avec un tas d'éléments « terminés » qu'aucun client n'avait demandés, tandis qu'une fonctionnalité attendue par trois ententes de vente restait à la position 47. L'équipe changeait sans cesse de contexte parce que le haut du backlog n'avait aucun thème cohérent. Et comme la carte de commande, touchée par les ruptures d'approvisionnement, bloquait une voie matérielle, tout ce qui en dépendait aurait dû descendre — mais personne ne l'avait déplacé, alors l'équipe butait sur du travail à moitié démarrable.
En nous asseyant avec la propriétaire de produit, le vrai problème est vite apparu. Elle ordonnait par demande, non par valeur. Chaque requête de partie prenante s'ajoutait à la pile à peu près dans l'ordre d'arrivée, et la « priorité » était une étiquette que les gens collaient à leurs propres éléments, pas une propriété de la liste dans son ensemble.
Réordonner par la valeur, délibérément
Nous n'avons pas introduit un cadre de notation lourd. L'équipe avait besoin de quelque chose d'exécutable à chaque séance d'affinage, sans cérémonie de tableur. Les questions employées pour comparer deux éléments du backlog étaient simples et concrètes :
Quelle valeur cela débloque-t-il, et pour qui ? Un engagement de revenus, une échéance réglementaire, un correctif qui empêche des clients de partir — cela passe avant un refactoring interne soigné, aussi satisfaisant soit-il.
Que nous coûte l'attente ? Certains éléments deviennent moins chers ou plus urgents avec le temps. Le travail sur la carte touchée par l'approvisionnement coûtait de plus en plus cher à retarder, car les délais glissaient; le rapport facultatif, non.
Est-ce réellement faisable maintenant ? Un élément bloqué par une pièce manquante ou une décision absente ne peut pas trôner en tête, peu importe sa valeur. L'ordre reflète la préparation autant que le mérite.
Cela réduit-il le risque ou l'incertitude ? Avancer une intégration risquée, même avant ses fonctionnalités séduisantes, livre souvent plus de valeur réelle qu'un autre incrément sans danger.
La propriétaire de produit a conservé sa responsabilité — l'ordre lui revient — mais elle l'a rendu transparent. Les dix premiers éléments avaient chacun une justification d'une ligne, visible par toute l'équipe et les parties prenantes. Ce seul changement a mis fin à la plupart du lobbying de couloir, car demander de passer devant exigeait désormais d'argumenter contre une raison affichée, et non contre le silence.
Ce qui a changé après deux sprints
La fonctionnalité bloquant les ventes a été livrée au sprint suivant au lieu de dériver; le backlog reflétait enfin les besoins réels de l'entreprise.
Le travail bloqué par l'approvisionnement est descendu et a cessé de fragmenter les sprints, l'équipe gardant un thème cohérent chaque cycle.
L'affinage est devenu plus rapide, car comparer des éléments par la valeur va plus vite que de rejuger qui a demandé en premier.
Les parties prenantes ont davantage fait confiance à l'ordre, justement parce qu'elles en voyaient le raisonnement.
Rien de tout cela n'est exotique. C'est la discipline ordinaire que le cadre Scrum réclame déjà, appliquée honnêtement. Un backlog n'est pas une liste de tâches dans l'ordre d'arrivée; c'est un énoncé vivant de ce qui compte le plus, ensuite. Quand une équipe à distance et sous contrainte d'approvisionnement réussit cet énoncé, tous les autres événements Scrum fonctionnent mieux — car l'équipe puise enfin au sommet d'une liste qui a du sens.
Si vos équipes de livraison sont occupées mais que l'ordre du travail ne reflète plus la valeur, le conseil en exécution de programmes et de projets de XNM peut vous aider à remettre une vraie priorisation au cœur de votre façon de livrer.