Le backlog

Le backlog est l'outil pour collecter les demandes et les affiner, afin d'alimenter l'équipe

Le backlog

Cela fait une vingtaine d’années que l’usage du mot backlog, provenant de Scrum, s’est répandu dans le domaine de l’agilité. Cette — déjà longue — histoire est passée par des moments différents : au début il s’agissait de le promouvoir comme outil de collecte en remplacement des gros documents de spécification, ensuite de montrer qu’il ne s’agissait pas simplement d’une liste mais qu’il y avait du travail de réflexion et d’amélioration — l’affinage — avant qu’un élément du backlog rentre dans un sprint. Maintenant l’enjeu porte sur l’usage du backlog en alignement avec la stratégie et un modèle de valeur.

Dans mon livre Scrum édition 6, je consacre trois chapitres au backlog, dans trois parties différentes du livre.

  • Dans la partie Boucles, un premier chapitre présente sa structure,
  • Dans la partie Prélude un deuxième montre comment élaborer le backlog initial aligné sur la vision,
  • Dans la partie Rites, un troisième décrit comment l’affiner au fil des sprints.

C’est dire si le backlog a une place importante dans Scrum. Cette place se situe dans ce qui est le mécanisme essentiel de l’agilité, les boucles de feedback.

Un outil pour les boucles

Voici un extrait de l’introduction de la partie Boucles de Scrum édition 6.

Le fonctionnement par boucles successives est au cœur de l’agilité. Avec Scrum, la boucle principale a une durée fixe et elle s’appelle le sprint. Pendant cette période :

  • les demandes des parties prenantes sont collectées dans le backlog qui alimente l’équipe ;
  • l’équipe coopère pour arriver à un résultat (le résultat du sprint);
  • les parties prenantes reçoivent ce résultat et rendent en retour leur feedback qui vient alimenter un nouveau cycle.

Le backlog est partie intégrante de ce mécanisme des boucles ; il ne doit pas être considéré comme un outil isolé de ce système vivant.

Un changement de paradigme

Revenons à l’histoire et aux débuts du backlog. À l’époque, il fallait convaincre que le backlog était une alternative crédible aux gros documents de spécification rédigés au début des projets. Voici un extrait un chapitre 8 Le backlog de mon livre Scrum.

Dans les projets traditionnels, la «spécification» se fait entièrement au début du projet et se concrétise dans un document qui décrit ce que va faire le produit, quelles sont les fonctions attendues et quel est le comportement souhaité. Ce document devient volumineux car on se dit qu’il faut tout écrire et tout détailler pour ne rien oublier afin que les développeurs sachent bien ce qu’ils ont à faire.

Plus tard, on s’aperçoit que le gros document ne leur a pas vraiment servi. Il n’a pas convenu non plus, encore un peu plus tard, à l’équipe chargée des tests fonctionnels. C’est vrai qu’il n’est pas facile de rentrer dans les deux cents pages pour quelqu’un qui ne connaît pas bien le domaine.

Et si le besoin change, évolue, la mise à jour est fastidieuse et peu de personnes se replongent dedans. D’ailleurs les personnes qui ont rédigé les spécifications au début sont certainement sur d’autres sujets. Et bien sûr, elles ne sont plus à jour après quelques semaines de développement, voire dès leur rédaction.

Avec Scrum, la démarche est fondamentalement différente: le travail à faire émerge progressivement par le biais d’une coopération continue entre les membres de l’équipe et le Product Owner, et grâce aux feedbacks réguliers donnés par les parties prenantes à chaque boucle.

L’outil de collecte des demandes et de partage du travail à faire s’appelle le backlog.

Constat : des antipatterns

L’usage du backlog s’est imposé progressivement. Les gros documents de spécification se sont faits plus rares. Cependant on a constaté des utilisations du backlog qui donnaient de mauvais résultats.

Voici quelques uns de ces antipatterns.

Le gros gros backlog tout plat

  • Constat : partant du principe que le backlog contient tout le travail à faire, il est rempli avec toutes les idées et les bugs en stock. Il finit par y avoir plus de 100 éléments, de taille et de statut variables.
  • Conséquences : le PO a beaucoup de mal à s’y retrouver, et encore moins ses coéquipiers. Il n’arrive pas à prioriser.

Le backlog de tickets

  • Constat : partant du principe qu’un backlog alimente l’équipe en travail, on continue à l’alimenter avec tous les tickets venant du bugtracker utilisé depuis des années, en plus des stories.
  • Conséquences : il y a deux entrées qui alimentent l’équipe, c’est le chaos.

Le backlog enfoui

  • Constat : pour que le Product Owner puisse définir les priorités comme il sait faire, il utilise pour le backlog un outil informatique de type tableur.
  • Conséquences : personne ne le voit, sauf le PO qui fait la saisie.

Le travail fantôme

  • Constat : partant du principe que le backlog est pour un produit, on n’y met pas ce qui ne concerne pas directement ce produit. Souvent, l’équipe travaille pour du support, sur des éléments qui ne sont pas dans le backlog.
  • Conséquences : le PO et les parties prenantes ne sont pas au courant. Pas de transparence.

Plusieurs backlogs pour une équipe

  • Constat : de nombreuses organisations passant à Scrum sont dans un schéma où une seule équipe travaille sur plusieurs projets en même temps. Elles continuent, avec un backlog par projet.
  • Conséquences : les problèmes de priorité ne sont pas résolus. Les gens sont interrompus par le multitâche.

Comment faire mieux ?

Un backlog n’est pas un todo liste. En effet, un élément du backlog a une plus grande complexité qu’une case à cocher. La réponse aux antipatterns s’appuie sur un approfondissement de trois attributs d’un élément de backlog :

  • sa taille,
  • sa valeur,
  • son état.

Pour la taille, le pattern fonctionnalité/story

Il met en évidence deux points de vue sur le backlog.

Après des années de pratique, j’en suis arrivé à la conclusion que le backlog comportait deux parties:

  • celle qui s’adresse à l’équipe, contenant les petits morceaux sur laquelle elle travaille ou va travailler bientôt,
  • l’autre pour communiquer avec les parties prenantes, qui contient des plus gros morceaux. Bien entendu, elle est aussi utile à l’équipe.

Il y a un seul backlog avec deux parties portant sur des éléments de visée différente :

  • une qui contient les petits morceaux, appelés stories.
  • l’autre pour les gros morceaux, appelés fonctionnalités.

Sur le sujet, voici un article du temps où je disais features.

Pour l’état, le pattern des bacs

La vie des éléments du backlog suit un pattern fractal basé sur l’approche scientifique.

Pour les stories, j’ai proposé depuis 2012 de les organiser selon leur état. J’ai appelé les différents containers des bacs.

J’en parle dans de nombreux articles de ce blog, voici le premier : Affinage de bac en bac.

États d'une story

Pour la valeur, le pattern des catégories (ou types)

Je propose de différencier selon la valeur d’une story. Cela permet de se poser des questions sur la valeur et ainsi de définir l’ordre dans le backlog.

Catégories de story

Points clés

Un outil PROUVÉ

En résumé, le backlog est plus qu’une liste des choses à faire par l’équipe ; il possède quelques caractéristiques remarquables, qui forment l’acronyme PROUVÉ.

  • Public : le backlog est public pour favoriser la transparence et faciliter le feedback.
  • Réduit : le backlog est de taille réduite pour rester dans la simplicité et faciliter son usage.
  • Ordonné : le Product Owner cherche à maximiser la valeur procurée aux utilisateurs tout en minimisant le travail pour y arriver ; il utilisera un modèle de valeur pour définir l’ordre dans le backlog.
  • Unique : le backlog est unique pour concentrer les efforts de l’équipe et éviter ainsi les effets nocifs du multi-tâche.
  • Vivant : le backlog est vivant parce qu’un produit évolue toujours (sinon il est mort) et parce qu’un élément a une vie qui passer par des états successifs (dont l’affinage).
  • Émergent : le backlog permet l’émergence de nouveaux éléments parce qu’il est impossible de savoir à l’avance quel est le bon produit ou service.

Cet acronyme vous donne les concepts fondamentaux pour un beau backlog.

Backlog d’équipe pas de produit

Pour finir cet article, un petit rappel avec un extrait de Scrum édition 6, page 85.

Dans la littérature sur Scrum, on trouve Product Backlog.

Je ne dis pas backlog du produit, mais simplement backlog, depuis longtemps. Il y a plusieurs raisons de le faire : c’est plus court à dire, on ne fait pas que du produit et surtout il est vraiment associé à l’équipe.

Voici deux questions qui se posent à considérer, à l’énoncé de Product Backlog, que le backlog serait exclusif d’un produit :

Une équipe travaille sur plusieurs versions d’un produit

  • Question : Notre équipe travaille sur un produit pour lequel nous avons un backlog, mais elle travaille aussi sur le support de l’ancienne version, où faut-il le mettre ?
  • Ma réponse : Dans le même backlog ! Si on ne fait pas apparaître ce travail, la conséquence sera le manque de visibilité.

Une équipe travaille sur plusieurs projets

  • Question : Dans notre organisation une seule équipe travaille sur plusieurs projets en même temps, est-ce qu’on a un backlog par projet ?
  • Ma réponse : Non. Ce serait perdre la notion d’équipe ! Une équipe possède un backlog dans lequel elle met tous ses travaux, même s’ils portent sur plusieurs produits ou projets.

Voir aussi