Reprendre le contrôle d’un backlog devenu fou

Les tickets techniques et fonctionnels s’accumulent, la dette grandit et votre backlog devient de plus en plus difficile à lire et à prioriser. Et si quelques ajustements simples suffisaient à reprendre le contrôle ? Dans cet article, découvrez comment réorganiser efficacement votre backlog en quelques clics, responsabiliser l’équipe et traiter la dette technique en continu.

L’état des lieux du backlog

Nous avons toutes et tous connu cela : le backlog d’un projet, qui avec les années devient de plus en plus rempli, jusqu’à devenir un immense trou noir où chaque ticket qui y sombre est oublié à jamais…

Ainsi, au fur et à mesure du temps, les besoins fonctionnels, les anomalies peu prioritaires et les tickets plus techniques créés par l’équipe de développement s’amoncellent. Et c’est normal ! Les besoins s’enchaînent, les priorités évoluent et ne permettent pas de dépiler tous ces tickets.

Et ça empire : lorsqu’il y a trop de tickets, le backlog cesse d’être consulté. La priorisation disparaît, les doublons se multiplient, certains tickets pourtant déjà couverts par d’autres réalisations subsistent. Votre backlog entre progressivement dans une lente nécrose…

L’effet est d’autant plus pervers qu’il finit par affecter le moral de l’équipe. Un backlog de plus en plus délaissé génère beaucoup de frustration, en particulier côté développement : des tickets techniques sont créés au fur et à mesure (« refactoriser telle partie », « optimiser tel script »…), mais là encore, ils se perdent dans le backlog.

Il faut donc revoir drastiquement la façon dont on organise ce backlog.

Première étape : nettoyage de printemps

Avant tout, il ne sert à rien d’essayer d’arranger un capharnaüm. Il convient donc de repasser sur tous les tickets et de jauger si ils sont encore pertinents. Nous vous conseillons donc d’abandonner tout ce qui n’est plus utile, de terminer ce qui a déjà été réalisé, de recréer les tickets dont le contenu n’est plus à jour.

Seconde étape : séparation du backlog en deux

Il faut savoir que votre backlog va avoir tendance à mélanger plusieurs choses :

• Le backlog fonctionnel : tous les besoins exprimés par les utilisateurs, qui s’inscrivent dans l’évolution du projet
• Les anomalies
• Le backlog technique : tous les tickets réalisés par l’équipe de développement, qui concernent des points techniques du projet

L’idée est donc de séparer ces tâches et d’ajouter un label “TECH” à tous les tickets techniques.

Le but est de créer deux backlog afin d’avoir en parallèle deux visions : fonctionnelle et technique.

Troisième étape : le backlog fonctionnel

Vous allez ensuite pouvoir créer votre backlog fonctionnel, notamment utilisé par le PO pour organiser ses sprints et qui regroupe à la fois les demandes fonctionnelles ainsi que les anomalies.

Pour ce faire, il est nécessaire de créer deux filtres :

• Tous les tickets non anomalies et non labellisés “TECH”
• Tous les tickets anomalies

Puis de construire un dashboard avec ces deux filtres :

Ainsi, d’un simple coup d’œil, le PO dispose d’une vue claire sur ses tickets et anomalies. Ce tableau dédié lui permet de les avoir facilement en visibilité et de pouvoir les prioriser.

Quatrième étape : le backlog technique

Il nous reste alors l’ensemble des tickets TECH :

Les tickets TECH (rangers du risque)

Si le résultat est déjà plus lisible, il est possible d’aller encore plus loin. Plutôt qu’une liste désordonnée (acceptable dans le cas d’un backlog technique peu rempli), vous pouvez créer une organisation par thèmes en listant ceux qui reviennent le plus souvent (par exemple : “sécurité”, “qualité”, “performance”, “UX”, etc.). Vous pouvez alors ajouter un nouveau label à chaque ticket et spécifier ce thème (“PRJCT_SECURITY”, “PRJCT_PERF”…).

Voici l’exemple d’un nouveau dashboard tech avec ces thèmes :

Les problématiques les plus importantes (sécurité, performance) sont ainsi bien visibles.

Nous pouvons également améliorer davantage ce dashboard en y affichant des KPI. Par exemple :

• Ajouter les SLO actuels au-dessus du filtre « performance » afin de constater le temps de latence moyen et de pouvoir noter les améliorations suite au dépilage public de ces tickets.
• Ajouter la note de sécurité donnée par Sonar, Checkmarx ou autre outil d’analyse au-dessus du filtre associé.

Dans l’idéal, chaque thème doit être relié à une valeur produite quantifiable par des indicateurs (performance, sécurité, satisfaction, couverture, etc.). Vous l’aurez compris : coder pour coder c’est bien, apporter du sens et de l’évolutivité à vos tickets techniques c’est mieux !

Cinquième étape : organisez-vous !

Une fois ces deux dashboards en place, la visibilité s’améliore, mais la démarche reste incomplète. Sans aller plus loin, le risque est de continuer à accumuler des tickets techniques qui ne seront jamais traités.

L’idée est donc de responsabiliser l’équipe technique, tout en réduisant la charge du PO. En effet, c’est à elle de refiner, estimer et voter en communauté, pour les tickets à insérer dans le sprint. Le PO, quant à lui, attribue une enveloppe de points associée qui servira de base pour le choix des tickets à embarquer pour chaque sprint. Ces tickets sont donc pleinement intégrés au sprint, permettant de résorber la dette technique du projet en continu.

Attention cependant, la séparation entre tech et PO n’est pas immuable : le PO peut tout à faire être inclus dans la gestion des tickets techniques (notamment ceux pouvant impacter le produit fonctionnellement). Les deux backlogs sont perméables, un ticket pouvant passer de l’un à l’autre selon les besoins ou les impacts.

Enfin, reztez vigilants sur la qualité de votre backlog ! Ne créez plus de tickets sans description dont « on verra le contenu plus tard », supprimez les tickets qui deviennent trop vieux et challengez-les régulièrement. Enfin, chacun est libre d’ajouter des tickets techniques, du développeur le plus junior au lead, car une bonne idée ou une piste pertinente peut venir de n’importe qui et être challengée lors du refinement. En revanche, le backlog technique ne doit pas se transformer en une accumulation de réflexions partielles ou non abouties.

Étape bonus : la spécialisation

Reste une problématique qui peut se présenter : la démultiplication des compétences nécessaires pour faire évoluer un projet. En effet, les projets nécessitent de plus en plus de compétences spécialisées : observabilité, UX, sécurité, performance, etc. Cela ne s’improvise pas (ou peu), et il peut être compliqué pour une même personne d’exceller dans chacun de ces domaines.

Pour améliorer cela, et si la taille de l’équipe le permet, chaque développeur peut se « spécialiser » sur un ou plusieurs thèmes pour lesquels il a une affinité. Là encore, cette approche renforce la responsabilisation : chaque thème est porté par une petite « sous-équipe » de développeurs, encouragés à se former et à approfondir le sujet. La spécialisation se fait ainsi naturellement, sans se disperser parmi la multitude de thèmes que peut contenir un backlog technique.

Conclusion

En conclusion, réorganiser son backlog technique ne relève pas d’un grand chantier, mais plutôt de quelques principes clairs et bien appliqués. Si vous ne deviez retenir que 3 choses :

1. Séparez clairement les backlogs (fonctionnel et technique) et appuyez-vous sur un système efficace de labels ou de thématiques (sécurité, performance, UX, etc.) pour améliorer la lisibilité et la priorisation.

2. Responsabilisez l’équipe sur quelques règles simples lors de la rédaction d’un ticket (titre clair, description explicite, deadline).

3. Donnez du sens aux tickets techniques en les reliant à des indicateurs concrets (SLO, score de sécurité, métriques de performance…), afin de mesurer leur impact et de les inscrire dans une logique d’amélioration continue.