Confusion entre issue tracker et backlog, et comment gérer la masse d'issues
Journal du samedi 25 avril 2026 à 22:27
À la fin de la note "Collecter les sujets dans un issue tracker pour ne pas se répéter", je disais :
Un backlog est une liste d'items souvent extraits de l'ensemble des issues de l'issue tracker — un sous-ensemble volontairement restreint et de meilleure qualité. Priorisée, maintenue à jour et régulièrement affiné, cette liste représente le travail potentiel sérieusement envisagé pour le produit. Lors du Sprint Planning, les parties prenantes — développeurs, produit et autres contributeurs concernés — discutent et arbitrent ensemble les priorités pour décider quels items intégreront le Sprint Backlog.
Est-ce que toutes les issues ouvertes du issue tracker sont un backlog ? La réponse est non.
J'ai vu plusieurs fois des Product Managers arriver dans une organisation et être effrayés par la quantité d'issues présentes dans l'issue tracker — ils essayaient de passer en revue toutes les issues, pensant qu'il s'agissait du backlog.
Il me semble que cette confusion entre issue tracker et backlog est très classique — j'ai moi-même probablement entretenu cette confusion.
Les personnes issues de la culture open source sont habituées aux issue tracker, tandis que les Product Managers sont généralement plus familiers avec les Product Backlog.
Face à toutes ces issues, certains Product Managers font des choix radicaux pour garder la maîtrise :
- fermer très rapidement toutes les issues non prioritaires
- interdire l'utilisation d'un issue tracker
- ignorer l'issue tracker et travailler dans un autre outil
Je ne conseille pas ces approches : elles suppriment d'un bloc ce qui fait la valeur d'un issue tracker (voir "Collecter les sujets dans un issue tracker pour ne pas se répéter").
À la place, je conseille dans un premier temps de ne pas se préoccuper de l'intégralité des issues, et de se concentrer uniquement sur les issues indiquées par ses collègues ainsi que sur celles que l'on a soi-même créées.
Pour suivre ces issues et constituer son backlog, je conseille d'utiliser des labels — sur GitLab, j'utilise par exemple backlog, backlog-stephane, next-sprint, next-next-sprint. Ces labels, combinés à des vues kanban, permettent à chaque membre de créer un backlog à partir d'un sous-ensemble restreint d'issues.
Cette approche par labels fonctionne, mais le problème est que ce workflow exige une rigueur importante et un protocole commun d'équipe — difficile à mettre en place sans un leadership fort qui l'impulse et le maintient.
C'est pour améliorer cette expérience utilisateur, que j'ai intégré les fonctionnalités suivantes dans la description du gestionnaire de projet de mes rêves :
- Permettre de créer des portfolios d'issue par utilisateurs.
- Implémenter un système de tags d'issues personnalisés où chaque utilisateur peut créer ses propres étiquettes. La visibilité de ces tags serait configurable : mode privé pour un usage personnel ou mode partagé pour les rendre disponibles aux autres utilisateurs.
De plus, j'imagine aussi une fonctionnalité permettant de « cacher » les issues, ou du moins de les rendre moins facilement accessibles aux nouveaux arrivants — non pas pour en interdire l'accès, mais pour réduire le bruit visuel et éviter qu'ils ne soient effrayés au point, après ce traumatisme, de les ignorer totalement.
Le triage régulier des issues (fermer et prioriser) est un travail laborieux, extrêmement difficile à maintenir dans la durée dès lors qu'un issue tracker contient beaucoup d'issues. Si je peux témoigner d'une chose, c'est que je n'ai probablement jamais réussi à le faire, ni vu quelqu'un y parvenir.
Concernant la fermeture des issues, certains projets configurent un système qui ferme automatiquement les issues après un certain temps sans activité. Personnellement, à la place de cela, je préfère un système qui poste un commentaire dans l'issue qui notifie et demande au créateur s'il juge qu'elle est toujours pertinente. En cas de non réponse après un temps imparti, l'issue peut être clôturée automatiquement.
Pour la priorisation des issues, toujours dans la description du gestionnaire de projet de mes rêves, j'ai imaginé la fonctionnalité suivante :
Journaux liées à cette note :
Alexandre m'a partagé le chapitre 7 « Bets, Not Backlogs » du livre Shape Up de Basecamp publié en 2019.
Il sait que j'apprécie cette méthode — j'ai lu le livre vers 2021-2022 — et me l'a envoyé parce qu'il ne comprend pas bien comment je peux adhérer à cette méthode alors qu'elle semble aller à l'encontre de ce qu'on a pratiqué ensemble.
Tout d'abord, je commence par préciser que Shape Up semble mélanger les notions de issue tracker et Product Backlog (voir note "Confusion entre issue tracker et backlog, et comment gérer la masse d'issues").
Ensuite, la méthode ne dit pas "no backlog", mais "no backlog commun" :
Des listes décentralisées
On n'a pas à choisir entre un backlog encombrant et ne rien retenir du passé. Chacun peut continuer à suivre pitchs, bugs, demandes ou idées de son côté, sans liste centrale.
Le support peut maintenir une liste des demandes ou problèmes qui reviennent souvent. Le produit suit les idées qu'il espère pouvoir façonner dans un cycle futur. Les développeurs tiennent une liste de bugs qu'ils aimeraient corriger dès qu'ils en ont l'occasion. Il n'y a ni backlog unique ni liste centrale, et aucune de ces listes n'alimente directement le processus des paris.
Shape Up ne m'apparaît pas comme une méthode qui interdit de partager des listes d'issues entre sous-groupes — c'est visible quand le texte dit que « le produit suit les idées qu'il espère pouvoir façonner dans un cycle futur » et que « les développeurs tiennent une liste de bugs qu'ils aimeraient corriger dès qu'ils en ont l'occasion ».
Ce qui me semble central dans Shape Up, ce n'est probablement pas tant le rejet d'un issue tracker commun. À mon sens, le cœur de la méthode réside ici :
Quelques paris potentiels
Que fait-on à la place ? Avant chaque cycle de six semaines, on organise une table des paris (betting table) où les parties prenantes décident ce qu'elles vont faire dans le cycle suivant. À cette table, on examine les pitchs des six dernières semaines — ou ceux que quelqu'un a délibérément ressortis et défendus à nouveau.
Rien d'autre n'est sur la table. Pas de longue liste d'idées à passer en revue. Pas de temps perdu à entretenir un backlog d'anciennes idées.
Cela signifie que si une issue n'a pas de "sponsor", c'est-à-dire, personne qui la met en avant, alors elle ne sera jamais priorisée. Les pitchs sont examinés à la betting table, mais Shape Up n'a pas de process continu de revue des issues en tant que backlog.
C'est pour moi l'idée la plus importante de ce chapitre par rapport à Scrum "mainstream" et cela ne me perturbe pas, car dans ma pratique Scrum, comme je le disais dans une précédente note, une issue sans sponsor n'a pratiquement aucune chance d'être sélectionnée lors d'un Sprint Planning :
Le triage régulier des issues (fermer et prioriser) est un travail laborieux, extrêmement difficile à maintenir dans la durée dès lors qu'un issue tracker contient beaucoup d'issues. Si je peux témoigner d'une chose, c'est que je n'ai probablement jamais réussi à le faire, ni vu quelqu'un y parvenir.
Imaginons un bug remonté il y a 8 mois sur l'export PDF.
- Scénario Scrum classique : le bug traîne dans le backlog, priorité "moyenne". À chaque Sprint Planning, le Product Owner fait défiler la liste, le voit, se dit "pas critique cette fois", et le repousse. Le bug survit parce qu'il est dans le système, pas parce qu'il est défendu.
- Scénario Shape Up : le bug n'existe nulle part dans un backlog central. Si un développeur pense qu'il vaut la peine d'y consacrer un cycle, il doit le re-pitcher activement à la prochaine betting table. Si personne ne le fait, le bug disparaît du radar — pas par décision active de le fermer, mais par absence de sponsor.
Dans ma pratique de Scrum, j'intègre déjà un betting table lors du Sprint Planning, et seules les issues proposées au sprint par un sponsor sont étudiées, par conséquent, cela me semble assez proche de ce que propose Shape Up.
Je préfère Shape Up à Scrum sur ce point précis de la betting table : il me semble que cette approche est plus honnête et reflète probablement mieux ce qui se passe réellement sur le terrain.