Explorer le Backlog

Le backlog pourrait se traduire par l’arriéré de travail… plus exactement, il correspond à la liste des choses à faire, connues à date.

Lorsqu’on parle d’un produit, le backlog correspond généralement à la liste des besoins auxquels ce produit doit répondre. Lorsqu’on parle d’une équipe, on peut parler de liste de tâches.

Dans la démarche agile, et plus spécifiquement en SCRUM, on peut identifier plusieurs types d’items (objets) contenus dans un backlog. Du besoin auquel le produit doit répondre (User Story) à la résolution d’anomalie, en passant par les demandes et la dette techniques.

Un backlog se doit de pouvoir être consulté par toutes les personnes intéressées par le travail de l’équipe. De fait, on a tendance à utiliser des outils de suivi de tickets pour faire vivre ce backlog. On peut cependant aussi suivre un backlog dans un outil plus rudimentaire comme un tableur en ligne par exemple.

Le backlog est généralement le cœur du fonctionnement d’une équipe agile. C’est en son sein que cette dernière va chercher, par elle-même (en auto-organisation), les sujets sur lesquels elle doit travailler. C’est également au travers de celui-ci que beaucoup d’échanges se font autour de la vision du produit et de la raison d’être de l’équipe. Enfin, un backlog se doit de proposer plusieurs prismes de lecture : priorisation, valeur, effort, sujets… De fait, à tout moment le backlog d’une équipe représente l’encours de cette dernière.

Que l’équipe soit en mode SCRUM, en démarche KANBAN ou tout autre méthode liée à la démarche agile, le backlog est présent et fait l’objet de beaucoup d’attention. Il permet de proposer une projection sur les jours / semaines / mois à venir… Sa gestion nécessite généralement la prise de responsabilité par une personne (le product owner par exemple) et/ou la création de règles explicites de fonctionnement (dans le cadre d’une démarche KANBAN par exemple).