Qu'est-ce qu'un backlog ?
Un backlog est la liste priorisée de tout ce qui reste à faire sur un produit : fonctionnalités, améliorations, corrections et travaux techniques. En agile, le product backlog (backlog produit) est l'unique source du travail à réaliser. Il est ordonné par valeur, le plus important en haut, et il bouge en permanence : on y ajoute, on y retire, on réordonne.
Le mot « backlog » désigne, littéralement, le travail accumulé en attente. Réduire le product backlog à une liste de tâches, c'est passer à côté de son intérêt : il sert à décider. Il rassemble au même endroit tout ce que le produit pourrait devenir, et il oblige à trancher ce qui passe avant le reste. À tout instant, un backlog bien tenu répond à une question : « qu'est-ce qui a le plus de valeur à construire maintenant ? »
Un élément de backlog n'est pas forcément une fonctionnalité. On y trouve des user stories (des besoins exprimés côté utilisateur), mais aussi des correctifs de bugs, de la dette technique à résorber, des travaux d'infrastructure ou de simples idées à explorer. Ce qui compte, c'est que chaque ligne représente un travail potentiel apportant de la valeur, et que le tout soit ordonné. Le product backlog est l'un des trois artefacts de Scrum, aux côtés du sprint backlog et de l'incrément.
Product backlog et sprint backlog : la différence
Le product backlog est la liste complète de tout ce que le produit devra faire un jour, priorisée et jamais figée. Le sprint backlog en est un sous-ensemble : les éléments que l'équipe s'engage à livrer durant le sprint en cours, plus le plan pour y parvenir. Le product owner possède le premier, les développeurs possèdent le second.
La confusion entre les deux est fréquente, et elle a des conséquences concrètes sur le pilotage. Le product backlog vit sur toute la durée du produit : il grossit, se réordonne, se nettoie sans cesse. Le sprint backlog, lui, naît à chaque sprint, lors de la planification, et disparaît à la fin. Il ne contient que ce que l'équipe a tiré du haut du product backlog et découpé en tâches réalisables.
| Critère | Product backlog | Sprint backlog |
|---|---|---|
| Contenu | Tout ce que le produit devra faire, à terme. | Ce que l'équipe s'engage à livrer ce sprint. |
| Horizon | Toute la vie du produit. | Un seul sprint (une à quatre semaines). |
| Responsable | Le product owner. | Les développeurs. |
| Stabilité | Évolue en continu, jamais figé. | Fixe pendant le sprint, sauf renégociation. |
Une bonne image : le product backlog est le réservoir, le sprint backlog est le seau qu'on y puise pour les deux prochaines semaines. Chaque sprint transforme une part du réservoir en incrément livrable, c'est-à-dire une version réellement utilisable du produit. Le reste attend son tour.
Comment construire un backlog avec des user stories
On construit un backlog en traduisant les besoins en user stories : de courtes phrases au format « En tant que [utilisateur], je veux [action] afin de [bénéfice] ». Chaque story décrit un besoin du point de vue de l'utilisateur, avec des critères d'acceptation clairs. On les rassemble, on les ordonne par valeur, et on affine seulement celles du haut de liste.
La user story (récit utilisateur) est l'unité de travail la plus répandue dans un backlog agile. Sa force, c'est qu'elle décrit un besoin, pas une solution technique. Prenez l'exemple : « En tant que client, je veux retrouver mes anciennes commandes afin de racheter un produit rapidement. » Elle ne dit pas comment coder la fonctionnalité, elle dit pourquoi elle existe. C'est ce qui laisse à l'équipe la liberté de trouver la meilleure implémentation.
Pour qu'une story soit exploitable, elle a besoin de trois choses :
- Une formulation orientée valeur : le « afin de » est le plus important, car il dit pourquoi on fait ce travail. Sans lui, on construit des fonctionnalités sans savoir ce qu'elles servent.
- Des critères d'acceptation : les conditions concrètes qui permettront de dire que la story est terminée et fonctionne. Ils évitent les malentendus au moment de la recette.
- Une taille raisonnable : une story doit tenir dans un sprint. Trop grosse, on la découpe en plusieurs stories plus petites, chacune livrable indépendamment.
Un piège classique consiste à vouloir tout détailler dès le départ. Inutile : seules les stories du haut du backlog, celles qu'on traitera bientôt, méritent d'être précises. Le bas de liste peut rester grossier, sous forme de grandes idées ou d'épopées (epics), que l'on découpera plus tard. On détaille au dernier moment responsable, quand on en sait le plus.
Prioriser le backlog : MoSCoW, valeur et effort
Prioriser un backlog, c'est décider quoi construire d'abord. Deux approches dominent : la méthode MoSCoW, qui classe les besoins en Must, Should, Could et Won't have ; et la matrice valeur/effort, qui privilégie ce qui rapporte le plus pour le moindre coût. La priorisation est une décision continue, pas un classement figé une fois pour toutes.
La priorisation est le cœur du métier du product owner. Un backlog non priorisé n'est qu'une liste de courses. La méthode MoSCoW est l'outil le plus simple pour s'accorder avec les parties prenantes. Elle range chaque besoin dans l'une de quatre cases :
- Must have (doit avoir) : indispensable. Sans lui, le produit ne remplit pas sa fonction. C'est le socle du MVP.
- Should have (devrait avoir) : important, mais pas vital dans l'immédiat. On le fera dès que possible.
- Could have (pourrait avoir) : souhaitable si le temps et le budget le permettent. Première variable d'ajustement.
- Won't have (n'aura pas) : écarté pour cette fois, mais consigné. C'est aussi utile de dire non explicitement que de dire oui.
L'autre grande logique est la matrice valeur/effort. On estime pour chaque élément la valeur apportée et l'effort nécessaire, puis on privilégie ce qui offre beaucoup de valeur pour peu d'effort. Ces « gains rapides » remontent en haut du backlog. À l'inverse, ce qui coûte cher pour peu de retour descend, voire sort de la liste. Ces méthodes ne s'excluent pas : en pratique, je combine MoSCoW pour cadrer l'essentiel avec les décideurs, et la logique valeur/effort pour ordonner finement le haut de liste. La priorisation reste vivante : elle se rejoue à chaque fois qu'on apprend quelque chose de nouveau sur les utilisateurs ou le marché.
Affiner le backlog : le raffinement
Le raffinement (ou backlog grooming) est l'activité continue qui consiste à clarifier, découper, estimer et réordonner les éléments du backlog. On y prépare les user stories du haut de liste pour qu'elles soient prêtes à entrer dans un sprint. Il n'a pas le statut d'événement officiel dans Scrum ; c'est une pratique régulière, souvent une courte session par sprint.
Un backlog n'est jamais « terminé ». Il s'entretient comme un jardin. Le raffinement, aussi appelé backlog grooming, désigne ce travail d'entretien permanent. À chaque session de raffinement, l'équipe et le product owner :
- clarifient les stories floues et ajoutent leurs critères d'acceptation ;
- découpent les éléments trop gros en morceaux livrables dans un sprint ;
- estiment l'effort des stories à venir, pour anticiper la planification ;
- réordonnent la liste selon les nouvelles priorités et suppriment ce qui n'a plus de sens.
L'objectif est d'avoir en permanence un haut de backlog « prêt » : quelques sprints d'avance de stories claires, estimées et priorisées, dans lesquelles l'équipe pourra piocher sans hésiter lors de la planification. On parle parfois de la règle du « definition of ready », le pendant amont de la définition de terminé. Le raffinement est le rituel discret qui fait toute la différence : un backlog raffiné rend les planifications fluides, tandis qu'un backlog négligé les transforme en séances de rattrapage interminables.
Qui gère le backlog : le product owner
Le product owner est le seul responsable du product backlog. Il décide de son contenu, de sa priorisation et de sa mise à jour. Les développeurs contribuent en estimant et en découpant les éléments, et les parties prenantes apportent leurs besoins, mais la décision finale sur l'ordre du backlog revient toujours au product owner.
La règle est claire dans Scrum : un backlog, un responsable. Cette responsabilité unique évite la paralysie où chacun voudrait imposer ses priorités. Le product owner arbitre entre les demandes des utilisateurs, les objectifs de l'entreprise et les contraintes techniques remontées par l'équipe. C'est un travail exigeant : il faut dire non souvent, et assumer un ordre de priorités que tout le monde ne partagera pas.
Attention à ne pas confondre les rôles. Le product owner porte le « quoi » et le « pourquoi » ; l'équipe décide du « comment ». Dans les projets où la maîtrise d'ouvrage et la maîtrise d'œuvre sont distinctes, le product owner se situe côté métier, un positionnement que je détaille dans mon repère sur les rôles MOA, MOE et AMOA. Quand ce rôle est tenu par une personne absente ou sans pouvoir de décision, le backlog se dégrade vite : priorités contradictoires, stories qui traînent, équipe qui avance à l'aveugle. Un bon backlog est d'abord le reflet d'un product owner qui fait son travail.
Un backlog n'est pas un dépotoir de demandes.
Ce que je vois le plus souvent, ce sont des backlogs à plusieurs centaines de lignes que plus personne n'ose ouvrir. Tout y est « prioritaire », donc rien ne l'est. Sur mes projets, je tiens un backlog court et brutalement priorisé : ce qui compte en haut, détaillé et prêt ; le reste en grandes idées, assumées comme floues. Ancien développeur, je sais découper une story pour qu'elle tienne dans un sprint ; pilote de projet, je sais dire non à une partie prenante sans casser la relation. C'est ce double regard qui garde un backlog vivant plutôt qu'un cimetière d'idées.
