Gestion du backlog

Objectif

Le backlog sert à enregistrer, suivre et prioriser les travaux qui restent. Il répond à une situation permanente: le volume de travail dépasse la capacité de le réaliser, et l'arbitrage doit donc se rejouer en continu.

Chaque item porte une description, un rang et, pour ceux du haut, une estimation de taille. La liste n'a pas de version finale approuvée: sa validité tient à la date de sa dernière revue. L'équipe la consulte pour décider ce qu'elle prend ensuite, les parties prenantes pour voir ce qui est imminent, ce qui est plus lointain et ce qui ne sera peut-être jamais réalisé.

La technique porte sur la tenue et l'ordonnancement du backlog. L'affinage du backlog, que les équipes appellent couramment le refinement, est l'activité continue qui découpe et détaille un item jusqu'à ce qu'il soit réalisable tel quel. Les deux se déroulent souvent dans la même séance et les confondre coûte cher. Une équipe qui passe sa revue à découper les trois items du haut ne réordonne jamais le reste, et le bas du backlog vieillit.

Usage

Quand l'utiliser

• Demande durablement supérieure à la capacité: plus d'items connus que l'équipe ne peut en traiter.
• Priorités appelées à bouger en cours de route: l'ordre courant décide de la suite du travail.
• Flux d'entrée permanent: défauts, demandes de changement et maintenance arrivent sans prévenir et s'arbitrent contre le reste.
• Travail hétérogène à arbitrer ensemble: user stories, exigences non fonctionnelles, défauts et tâches documentaires dans une seule file.
• Capacité libérée par à-coups: l'équipe tire l'item suivant dès qu'une place se libère.

Quand ne pas l'utiliser

• Périmètre contractuel figé et séquencé avant l'exécution: préférer un référentiel de périmètre et un échéancier de projet.
• Poignée d'items sans flux d'entrée: une liste de tâches suffit, la cadence de revue coûte plus qu'elle ne rend.

Description

Ce qui entre dans le backlog

Un item entre dans le backlog s'il a de la valeur pour une partie prenante. Le critère est large à dessein. La liste des types d'items l'est tout autant: cas d'utilisation, user stories, exigences fonctionnelles et non fonctionnelles, éléments de conception, commandes clients, demandes de changement, défauts, reprises planifiées, maintenance, items de risque, jusqu'à « tenir une présentation » ou « rédiger un document ».

L'erreur la plus répandue est de traiter le backlog comme une liste de fonctionnalités. Une équipe qui n'y inscrit que des user stories arbitre ses défauts, sa dette technique et ses obligations documentaires dans une file parallèle qui n'entre jamais en concurrence avec le produit. La maintenance passe donc après tout le reste parce qu'elle n'a jamais été mise en compétition avec quoi que ce soit. Le suivi des items reste utile pour porter le cycle de vie d'un défaut ou d'un problème ouvert; le backlog, lui, porte l'arbitrage entre ce défaut et tout ce qui le concurrence.

Le droit d'ajouter un item se décide explicitement. Trois formes se rencontrent: une personne unique détient l'autorité d'ajout, un comité tranche par consensus ou la responsabilité est déléguée au business analyste. S'y ajoutent des règles d'entrée automatique, par exemple l'obligation d'inscrire tout défaut majeur dès sa qualification. Sous une gouvernance du changement formelle et auditable, le backlog alimente le processus, mais le registre des demandes de changement reste le document opposable. Une équipe qui n'a jamais tranché cette question l'a tranchée par défaut: tout le monde ajoute et le backlog devient l'endroit où l'on range ce qu'on ne veut pas oublier.

Le détail se concentre en haut

Les items proches du haut sont décrits en détail, avec une estimation de taille et de complexité assez fiable pour en déduire un coût et une charge. Cette taille s'exprime en unité relative, en points ou en tailles de t-shirt selon l'équipe. Un item ajouté loin du sommet reçoit le minimum de travail permettant de comprendre ce qu'il implique. Quand sa priorité monte, il est revu, éventuellement décomposé et estimé plus finement.

Cette concentration est ce qui rend la technique tenable à toute taille: élaborer trois cents items au même niveau de détail coûte des semaines, produit des chiffres périmés avant d'être utilisés et alimente une décision qui ne porte que sur les premiers items. Le corollaire est une discipline d'équipe: refuser de détailler un item du bas tant que son rang ne bouge pas.

Le coût et la charge consommés par les items terminés servent à recalibrer les estimations de ceux qui restent: une équipe qui livre régulièrement au double de son estimation apprend cet écart et le répercute sur le reste du backlog. L'estimation devient ainsi un acte récurrent, sur le modèle de l'estimation par vagues.

La priorité, en deux temps

Les items sont priorisés les uns par rapport aux autres. Cette priorité relative bouge: les besoins des parties prenantes changent, des dépendances apparaissent entre items et les règles de gestion du backlog pèsent aussi sur l'ordre.

À l'entrée, la priorisation est grossière: haute, moyenne ou basse. Les items du groupe haut sont revus plus souvent, puisqu'ils sont les candidats du prochain travail engagé. Pour les départager, un classement plus fin s'applique à l'intérieur de ce groupe, par exemple un rang numérique fondé sur une mesure de valeur. Le BABOK décrit ce mécanisme sans nommer de méthode. MoSCoW, le WSJF et le coût du retard en sont des mises en œuvre possibles; le coût du retard, formalisé par Reinertsen, se prête bien à un rang rejoué à chaque revue, parce qu'il produit un nombre comparable entre des items de nature différente.

Le passage du groupe au rang est la différence entre le regroupement et le classement. Le premier range les items dans quelques catégories partagées, sans ordre à l'intérieur d'une catégorie. Le second attribue à chaque item une position unique. Un backlog vit avec les deux: un regroupement sur l'ensemble, un classement sur la tête de liste.

Le BABOK parle de priorisation et de priorité relative. Le Scrum Guide décrit le Product Backlog comme une liste ordonnée et n'emploie pas le vocabulaire de la priorisation: c'est le Product Owner qui répond de cet ordre. Les deux vocabulaires désignent des pratiques voisines sans être interchangeables. Employer le mot du référentiel dont on parle évite l'ambiguïté en séance.

Sélection et sortie des items

Quand de la capacité se libère, l'équipe revoit le haut du backlog et sélectionne en fonction de cette capacité, des dépendances entre items et de ce qu'elle comprend à cet instant de leur taille et de leur complexité. Le rang guide la sélection sans la dicter: un item de rang 2 dont le prérequis n'est pas prêt cède la place au suivant.

Un item sort du backlog pour deux raisons: il est terminé ou une décision a été prise de ne plus y travailler. Un item retiré peut revenir. Le BABOK en donne quatre motifs: un changement important des besoins des parties prenantes, un travail plus long que ce qui avait été estimé, d'autres items prioritaires qui débordent leur propre estimation ou un produit livré porteur de défauts. Retirer un item est donc une décision peu coûteuse: on peut purger sans hésiter et réinscrire plus tard.

Que dit la taille du backlog?

Le nombre d'items se suit dans le temps. Un backlog qui grossit signale une hausse de la demande ou une baisse de la productivité; un backlog qui se vide signale une baisse de la demande ou une amélioration du processus de production. La courbe seule ne dit pas laquelle s'applique. La cause se cherche à chaque inflexion, du côté du flux d'entrée comme de la capacité livrée.

Une organisation en tient souvent deux: un backlog global qui rassemble tout ce qui est connu et un second, réduit à ce qui sera réalisé dans un horizon court, alimenté par le premier. La distinction sert quand les deux publics diffèrent, un comité de portefeuille sur le premier et une équipe de réalisation sur le second. Elle se paie d'un travail de synchronisation: un item promu dans la liste courte doit quitter la file d'attente de la liste globale, sous peine d'exister et d'être estimé deux fois.

Trois pièges qui vident un backlog de son sens

Le premier est le backlog devenu un dépôt: passé un certain volume, il devient lourd à tenir. La revue ne parcourt plus que les vingt premiers items. Un item ajouté il y a six mois avec trois mots de description n'est plus compris par personne. La perte d'information est d'autant plus rapide que le détail y est faible par construction. La parade est d'assumer la sortie: un item que deux revues successives n'ont pas su expliquer se retire, quitte à revenir décrit correctement.

Le deuxième est la cadence absente. La revue périodique de l'ensemble tient tout le reste, puisque c'est là que les changements de besoins se traduisent en changements de rang. Sans intervalle planifié, la revue se réduit à la préparation de l'itération suivante et l'ordre du bas se fige.

Le troisième est l'ordre dont personne ne répond. Un rang produit par un tour de table, sans critère consigné, se conteste à chaque séance et se rejoue à chaque changement d'interlocuteur. Nommer qui arbitre et consigner le critère coûte quelques minutes par revue et rend l'ordre défendable le jour où quelqu'un demande pourquoi son item est passé derrière un autre.

Considérations IA

Trois usages se justifient sur un backlog volumineux. Le premier est la détection de doublons sémantiques: repérer que deux items formulés différemment décrivent le même besoin, avant que les deux soient estimés puis réalisés. Sur plusieurs centaines de lignes accumulées en deux ans, c'est un travail qu'aucune revue humaine ne mène. Le deuxième est l'analyse de vieillissement: faire remonter les items qu'aucune revue n'a touchés depuis N cycles, pour qu'une personne décide de les reprendre en détail ou de les retirer. Le troisième est la rédaction d'une première description détaillée et de critères d'acceptation quand un item passe du bas vers le haut, à partir de ce que l'item porte déjà. Une fourchette d'estimation dérivée du débit historique sur des items comparables s'y ajoute au besoin; le business analyste retravaille ce texte et le fait valider.

La machine ne réordonne pas: le rang traduit la valeur pour des parties prenantes et un arbitrage entre elles, qui ne s'infère pas du texte des items. Elle ne fusionne ni ne supprime un doublon présumé sans confirmation humaine, parce qu'un item qui paraît redondant peut se rouvrir pour des raisons que le texte ne contient pas. Elle ne livre pas d'estimation sans montrer sur quoi elle repose, sans quoi personne ne peut la défendre en revue. Enfin, le contenu des items est un contenu de projet comme un autre: le backlog d'un espace assuré porte des libellés de prestations, des identifiants de dossiers et des descriptions de défauts touchant des données de santé. L'outil qui traite ces textes relève des mêmes exigences de protection des données que le système lui-même.

Exemples

La position d'un item commande son niveau de détail et d'estimation. Le backlog ci-dessous est celui de l'équipe qui modernise l'espace assuré d'un assureur maladie.

Une user story, une exigence non fonctionnelle, un défaut, un cas d'utilisation, une demande de changement, un risque et une tâche de rédaction se disputent la même file et le même haut de liste. Le défaut de décompte passe devant l'accessibilité de l'écran de connexion parce qu'il touche un montant affiché à l'assuré, arbitrage qu'aucune des deux files séparées n'aurait rendu possible.

La revue du 12 mars a fait entrer le défaut de décompte dans le groupe Haute, au rang 3, le jour où le service clientèle a compté onze appels sur le même solde faux; elle a fait redescendre en Basse la notification par SMS, tenue en Moyenne depuis l'automne, quand le courriel a suffi. La demande de prise en charge à l'étranger attend deux choses avant d'être estimée: la confirmation que ces traitements relèvent de la couverture de base et la réponse du partenaire de facturation sur le format d'échange. Tant que ces deux points sont ouverts, la découper coûterait un travail à refaire; son ordre de grandeur suffit à la comparer aux autres.

Visualisations

Le livrable est le tableau lui-même, écrit en HTML. L'usage de l'artefact tient dans trois opérations que l'image perd: trier sur le rang, filtrer sur un type et relire une ligne pour justifier une position.

Le mécanisme qui produit ce tableau ne rentre pas dedans. La concentration du détail au sommet est une propriété spatiale: elle se voit quand les items du haut occupent de la place, avec leur description et leur badge d'estimation, quand ceux du milieu se réduisent à un libellé et quand ceux du bas ne sont plus que des marques sans étiquette. Deux flèches complètent la lecture, l'une qui sort du sommet pour la sélection et l'autre qui remonte pour la revue périodique.

Coût

Outils

Pour une petite équipe, un tableur partagé ou un tableau Kanban, physique ou dans un outil léger comme Trello, tient le rôle sans rien coûter. L'ordre est la position de la ligne ou de la carte, le type est une colonne ou une étiquette et la revue consiste à déplacer. Au-delà de quelques dizaines d'items, l'absence d'historique et de filtrage rend le suivi de la taille impraticable.

À l'échelle d'une équipe produit ou d'un département, Jira, Azure DevOps Boards et leurs équivalents portent nativement ce que la technique demande: un rang par glissement, un typage des items qui permet de mélanger stories, défauts et risques dans une file unique et un historique de débit qui alimente le recalibrage des estimations. Ces outils rendent aussi le vieillissement mesurable, par une requête sur la date de dernière modification.

Quand le backlog est alimenté par une gouvernance formelle de la demande, les modules de demande ou de portefeuille d'une plateforme de gestion des services, ServiceNow par exemple, font le lien entre la réception des demandes et la file de réalisation. L'anti-outil reste la présentation: un backlog dans une série de diapositives ne se trie pas, ne se filtre pas et est faux le lendemain de sa dernière mise à jour.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.2 Backlog Management: la définition du backlog, les six décisions de sa gestion, la liste des types d'items, la gouvernance de l'ajout, la priorisation en plusieurs phases, la concentration du détail au sommet, les motifs de sortie et de réinscription, la lecture des variations de taille et les limites citées.
• Ken Schwaber et Jeff Sutherland, The Scrum Guide (2020), section « Product Backlog »: le Product Backlog défini comme une liste ordonnée dont le Product Owner répond et l'affinage du backlog présenté comme une activité continue.
• Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing: le coût du retard comme mesure économique de valeur relative, utilisable pour départager les items d'un même groupe de priorité.