Product Backlog

  • Concept
  • Intermédiaire
  • Transversal
  • Toujours utilisé

En bref

Le Product Backlog est la liste ordonnée de tout ce qui reste à faire sur un produit, gérée par le Product Owner.

Définition complète

Le Product Backlog (que l’on peut traduire par « carnet de commandes du produit ») est, dans les méthodes agiles comme Scrum, la liste de tout ce qu’il reste à faire sur un produit : nouvelles fonctionnalités, corrections, améliorations. Cette liste est classée par ordre de priorité, et évolue en permanence : des éléments s’y ajoutent, d’autres sont retirés ou reformulés, au fil des besoins des utilisateurs et des décisions de l’équipe.

Par exemple, le Product Backlog d’une application de réservation de rendez-vous peut contenir, dans cet ordre : « ajouter un rappel par SMS », « permettre l’annulation en ligne », « améliorer l’affichage sur mobile », chacun classé selon son importance pour les utilisateurs.

Attention : contrairement à une simple liste de tâches, le Product Backlog n’est jamais figé ni complet ; il continue d’évoluer tant que le produit existe, et seuls les éléments les plus prioritaires sont détaillés précisément.

À quoi ça sert

Le Product Backlog sert à donner une visibilité claire, à toute l’équipe, sur ce qui reste à construire et dans quel ordre, sans avoir besoin de tout replanifier à chaque réunion. Il évite de perdre des idées ou des demandes, même celles qui ne seront traitées que plus tard.

Il sert aussi à faire des choix explicites de priorité : en plaçant certains éléments en haut de la liste et d’autres plus bas, l’équipe et le Product Owner décident ensemble de ce qui apporte le plus de valeur en premier, plutôt que de traiter les demandes dans l’ordre où elles arrivent.

Enfin, il facilite le dialogue avec les parties prenantes externes, comme des clients ou une direction : montrer le Product Backlog permet d’expliquer pourquoi telle fonctionnalité arrive avant telle autre, de façon transparente.

Cas d'usage typiques

– Ajouter une nouvelle demande utilisateur au Product Backlog plutôt que de l’insérer directement dans le travail en cours.
– Réordonner le Product Backlog pour faire remonter une fonctionnalité devenue plus urgente.
– Détailler précisément les premiers éléments du Product Backlog avant de les faire réaliser par l’équipe.
– Nettoyer le Product Backlog en retirant les éléments devenus obsolètes ou inutiles.
– Présenter le Product Backlog à un client pour justifier l’ordre de développement des fonctionnalités.

Ce que tu sauras faire

Savoir organiser un Product Backlog en priorisant les éléments les plus utiles, et comprendre pourquoi cette liste reste toujours vivante et jamais figée.

Mises en situation

Situation 1 : lancement d’une nouvelle application

Contexte : Une start-up développe une application de covoiturage entre salariés d’une même zone d’activité.

Application : Le Product Owner construit un Product Backlog avec les fonctionnalités essentielles en haut et les fonctionnalités secondaires plus bas.

Résultat attendu : L’équipe développe d’abord les fonctionnalités essentielles, ce qui permet de lancer une première version utilisable plus rapidement.

Situation 2 : ajout d’une demande client

Contexte : Plusieurs clients d’un logiciel de facturation demandent la possibilité d’exporter leurs données en un clic.

Application : Le Product Owner ajoute cette demande au Product Backlog et la fait remonter en priorité, vu le nombre de demandes reçues.

Résultat attendu : La fonctionnalité est développée dans les semaines suivantes, ce qui réduit les réclamations et améliore la satisfaction des clients existants.

Situation 3 : nettoyage d’un Product Backlog trop long

Contexte : Le Product Backlog d’un logiciel interne contient plus de 200 éléments accumulés depuis trois ans, dont beaucoup ne sont plus pertinents.

Application : Le Product Owner organise une revue du Product Backlog avec l’équipe pour retirer les éléments obsolètes et regrouper les demandes similaires.

Résultat attendu : Le Product Backlog passe à 60 éléments réellement pertinents, ce qui facilite les décisions de priorisation.

Application guidée : prioriser trois éléments du backlog

Contexte : Un Product Backlog contient trois éléments : une fonctionnalité demandée par un seul client mais très complexe à développer, une correction de bug qui gêne 40 % des utilisateurs, et une nouvelle fonctionnalité esthétique peu demandée mais rapide à réaliser.

Question : Dans quel ordre traiter ces trois éléments ?

Résultat attendu : La correction de bug qui gêne 40 % des utilisateurs devrait passer en premier, car elle affecte beaucoup de monde ; la fonctionnalité esthétique rapide peut suivre si elle apporte une valeur réelle ; la fonctionnalité complexe demandée par un seul client peut être repoussée ou reformulée, sauf si ce client est stratégique pour l’entreprise.

Application guidée : rédiger un élément de backlog clair

Contexte : Un élément du Product Backlog est rédigé ainsi : « améliorer les notifications », sans plus de précision, ce qui empêche l’équipe de commencer à travailler dessus.

Question : Comment reformuler cet élément pour qu’il devienne exploitable par l’équipe ?

Résultat attendu : Préciser qui est concerné, quel problème est résolu et quel résultat est attendu, par exemple : « en tant qu’utilisateur, je veux recevoir une notification 24 heures avant mon rendez-vous, pour ne pas l’oublier », avec un critère clair permettant de vérifier que la fonctionnalité est terminée.

Pour bien le retenir

L'analogie

Le Product Backlog ressemble à la liste de travaux d’un artisan qui rénove des maisons pour plusieurs clients à la fois. Chaque nouvelle demande vient s’ajouter à sa liste, mais il ne peut pas tout faire en même temps : il classe les demandes selon leur urgence et leur intérêt, traite les plus prioritaires en premier, et garde les autres en réserve pour plus tard, sachant que la liste s’allongera encore avec de nouvelles demandes.

« Le Product Backlog, c'est la liste jamais terminée de tout ce qu'il reste à construire, rangée par priorité. »

Pièges à éviter

À ne pas confondre avec

Une confusion fréquente consiste à croire que le Product Backlog doit être entièrement détaillé dès le départ : en réalité, seuls les éléments les plus prioritaires, ceux qui seront traités bientôt, méritent d'être précisés finement ; les éléments plus lointains peuvent rester vagues.

Une autre erreur est de laisser n'importe qui ajouter des éléments et changer l'ordre de priorité sans coordination : la décision finale sur l'ordre du Product Backlog revient normalement au Product Owner, pour garder une cohérence d'ensemble.

Enfin, certains confondent le Product Backlog avec le travail prévu pour la période en cours, souvent appelé « sprint » : le Product Backlog contient tout, y compris ce qui ne sera traité que dans plusieurs mois, alors que le travail du moment n'en est qu'un petit extrait.

Évolution historique

Apparition : Notion issue des méthodes agiles, popularisée avec le cadre Scrum à partir de la fin des années 1990 et du début des années 2000

Quels changements depuis l’arrivée de l’IA ?

Avant

Le Product Backlog était tenu dans des documents partagés ou des tableaux physiques (post-it sur un mur), mis à jour manuellement par le Product Owner.

Aujourd’hui

Des outils numériques de gestion agile intègrent désormais des fonctions d’aide basées sur l’intelligence artificielle, capables par exemple de suggérer une reformulation plus claire d’un élément du backlog, de repérer des doublons, ou d’aider à analyser les retours utilisateurs pour proposer de nouveaux éléments à ajouter. La décision de priorité reste toutefois un choix humain, guidé par la stratégie produit et la connaissance des utilisateurs.

Évolution historique

Fin des années 1990 : les premières formes de méthodes agiles émergent, en réaction aux méthodes de gestion de projet jugées trop rigides.

Début des années 2000 : le cadre Scrum formalise la notion de Product Backlog comme liste centrale et évolutive des besoins d’un produit.

Années 2000-2010 : les méthodes agiles se diffusent largement dans le développement informatique, popularisant le terme au-delà des équipes techniques.

Années 2010 : des outils numériques dédiés remplacent progressivement les post-it physiques pour gérer le Product Backlog.

Depuis les années 2020 : certains outils intègrent une assistance par intelligence artificielle pour aider à rédiger, classer ou analyser les éléments du Product Backlog.