Product backlog

Product backlog : définition

Un product backlog est la liste complète et priorisée de tout ce qui est à faire sur un projet logiciel : fonctionnalités à développer, corrections à apporter, améliorations envisagées. Cette liste n'est jamais figée et se réorganise en continu selon ce qui a le plus de valeur à un instant donné.

C'est un concept central dans les méthodologies agiles et provient à l'origine de la méthodologie Scrum, l'un des frameworks agiles les plus utilisés en développement logiciel.

Le product backlog se différencie du sprint backlog, deux niveaux distincts souvent confondus :

• Le product backlog est la liste complète de tout ce que l'équipe pourrait développer sur le produit dans son ensemble, sans limite de temps. Mais attention, ce n'est pas une boîte à idées en vrac. C'est plutôt une liste de courses triée par priorité : tout ce qu'il reste à faire sur le produit, mais classé selon ce qui compte le plus.
• Le sprint backlog, quant à lui, est un sous-ensemble du product backlog : ce sont les éléments que l'équipe sélectionne pour les réaliser pendant un cycle de travail donné

La relation entre les deux est à sens unique : le sprint backlog puise dans le product backlog, jamais l'inverse. Un élément quitte le product backlog pour entrer dans un sprint backlog seulement lorsqu'il est jugé suffisamment clair et prêt à être développé, ce qui rejoint l'étape de backlog refinement décrite plus loin dans cet article.

Cette distinction a un intérêt concret pour un dirigeant qui suit un projet : le product backlog donne la vision d'ensemble et l'avancement global, tandis que le sprint backlog répond à la question plus immédiate de "qu'est-ce qui sera livré dans les deux prochaines semaines".

Qui est responsable du product backlog ?

La responsabilité du product backlog est généralement portée par le Product Manager (ou le Product Owner dans Scrum), ou plus largement par la personne qui porte la vision produit lorsque l'équipe est réduite. Il arbitre les priorités selon leur valeur business, les contraintes techniques remontées par l'équipe de développement, et les délais fixés.

Product backlog vs cahier des charges : deux outils différents

Il existe parfois une confusion entre product backlog et cahier des charges. Le cahier des charges décrit ce que le projet doit accomplir dans son ensemble. Généralement, il est rédigé une seule fois, en amont du projet. Le backlog produit est sa traduction opérationnelle, sous format liste, de ce qui doit être développé pendant toute la durée du projet. En gros, le cahier des charges pose la destination, le product backlog organise le chemin pour y arriver.

Les caractéristiques d'un bon product backlog

L'expert agile Claude Aubry a proposé un moyen simple de retenir ce qui fait un bon backlog produit, à travers l'acronyme PROUVÉ :

• P comme Public : il est accessible à toute l'équipe concernée.
• R comme Réduit : une liste trop longue jamais triées devient décourageante à consulter et perd son utilité.
• O comme Ordonné : on cherche à maximiser la valeur procurée aux utilisateurs tout en minimisant le travail en utilisant un modèle de valeur, les éléments qui comptent le plus apparaissent en premier.
• U comme Unique : un seul par projet.
• V comme Vivant : parce qu'un produit logiciel évolue toujours, le product backlog doit donc être mis à jour et réordonné en continu.
• É comme Émergent : de nouveaux éléments s'y ajoutent au fil du projet.

Comment gérer un product backlog ?

Les niveaux de granularité d'un backlog produit : de l'idée large à la tâche précise

Un product backlog bien construit organise l'information à plusieurs niveaux, du plus large au plus précis :

• EPIC : un besoin large, qui touche souvent plusieurs fonctionnalités différentes en même temps et qui n'est pas encore assez précis pour être développé directement. Une EPIC se découpe progressivement, au fur et à mesure que chaque partie du besoin devient claire, plutôt que d'être développée d'un seul bloc.
• Feature : un bloc fonctionnel identifiable à l'intérieur d'une EPIC.
• User story : un élément concret du backlog, formulé du point de vue de la personne qui l'utilisera. C'est le niveau le plus utilisé au quotidien par le Product Owner, le Product Designer et les développeurs.
• Sous-tâche : le découpage technique d'une user story en étapes plus petites.

Exemple de granularité avec le parcours d'achat sur un site e-commerce :

EPIC "Permettre à un client d'acheter un produit sur le site, de la sélection jusqu'à la confirmation de commande."

Cette EPIC est trop large pour être développée d'un bloc : elle couvre la navigation, le panier, le paiement et la confirmation. Elle se découpe en plusieurs features :

• Feature 1 : Gestion du panier
• Feature 2 : Paiement en ligne
• Feature 3 : Confirmation et suivi de commande

Chaque feature se décompose ensuite en user stories, par exemple pour la feature 2 :

• "En tant que client, je veux payer par carte bancaire, pour finaliser mon achat sans créer de compte au préalable."
• "En tant que client, je veux recevoir un message d'erreur clair si mon paiement échoue, pour comprendre ce qui s'est passé et réessayer."

Cette dernière user story se découpe à son tour en sous-tâches au moment de la développer : intégration de l'API de paiement (Stripe ou équivalent), gestion des cas d'erreur retournés par le prestataire de paiement, affichage du message côté interface, etc.

Comment délimiter une EPIC ?

Une EPIC se délimite par l'objectif d'un acteur donné, pas par tout ce qui touche de près ou de loin au même sujet. Dans notre exemple, on pourrait se demander si "Ajouter des articles au catalogue" fait parti du scope. En effet, cela peut sembler logique de permettre l'ajout d'article sur le site afin qu'un client puisse réaliser un achat.

Cependant, l'EPIC "Permettre à un client d'acheter un produit" concerne l'acteur client, avec pour objectif de finaliser un achat. Tandis qu'"Ajouter des articles au catalogue" concerne un acteur différent : l'équipe interne qui gère le catalogue (marchandiseur, gestionnaire produit). Ici, l'objectif est différent : alimenter le site en produits vendables.

Ce sont deux parcours qui ne se croisent jamais du point de vue de l'utilisateur final, ils appartiennent donc à deux EPIC distinctes.

Les outils pour gérer un backlog produit

Plusieurs outils permettent de le structurer et le suivre, avec des niveaux de complexité différents :

• Jira : conçu pour un suivi agile poussé, avec liaison directe au code et gestion fine des sprints. Pertinent sur des projets de grande échelle.
• Notion : structuration flexible en liste ou en base de données, adaptée à une petite équipe qui veut personnaliser son organisation.
• Trello : présentation en tableau par colonnes, simple à prendre en main, bien adapté à un backlog de taille réduite.
• ClickUp : combine gestion de tâches et vues multiples (liste, tableau, calendrier), utile dès que le product backlog commence à grossir.
• Asana : orienté gestion des tâches et collaboration d'équipe, pertinent quand plusieurs personnes interviennent sur des projets liés.
• Monday.com : organisation visuelle et personnalisable, proche de ClickUp dans l'usage.

Dans La Boîte Tech, nous travaillons principalement avec Notion ou ClickUp. Le choix de l'outil dépend du projet : l'objectif étant de retenir celui qui restera réellement utilisé dans la durée.

Les étapes pour construire un bon product backlog

1. Poser la vision du projet

D'abord, l'objectif global doit être clair et partagé par toutes les personnes concernées.

2. Lister les besoins en vrac

Ensuite, cette étape permet de sortir toutes les idées, demandes et besoins identifiés, sans filtre à ce stade.

3. Regrouper et clarifier les besoins

L'équipe regroupe par thème les besoins listés en vrac, puis les rattache à une EPIC ou une feature.

Par exemple, l'équipe pourrait recevoir en vrac des demandes comme "il faut pouvoir payer par PayPal", "on doit prévenir le client si le paiement rate". Une fois regroupées, elles se rattachent toutes à la même feature "Paiement en ligne".

Une demande brute du type "il faut pouvoir filtrer les commandes" est encore floue : filtrer quoi ? pour qui ? dans quel but ? Cette étape sert à poser ces questions avant de figer une formulation.

4. Formuler chaque élément clairement

Une bonne pratique consiste à écrire chaque élément du point de vue de la personne qui l'utilisera : "en tant que [rôle], je veux [action], pour [bénéfice]". Cette formulation simple évite les malentendus sur ce que l'élément recouvre vraiment.

5. Prioriser avec une méthode

Les demandes ne sont pas classées par ordre d'arrivée mais par impact réel. Plusieurs méthodes aident à la priorisation :

• MoSCoW : classer chaque élément en "Must have" (indispensable), "Should have" (souhaitable), "Could have" (possible si le temps le permet) ou "Won't have" (pas pour cette fois). C'est la méthode la plus simple à s'approprier pour un non-spécialiste.
• Valeur vs effort : positionner chaque élément selon ce qu'il apporte et ce qu'il coûte à réaliser, pour repérer en premier ce qui rapporte beaucoup pour un effort raisonnable.
• ICE / RICE : des grilles de notation plus poussées (Impact, Confiance, Effort, et Reach pour RICE) utilisées surtout sur des backlog volumineux avec de nombreuses parties prenantes.

Exemple de priorisation avec la méthode MoSCoW

Un backlog produit priorisé associe à chaque élément un niveau d'urgence explicite. Par exemple, voici quelques features possibles pour un logiciel de gestion des interventions terrain, priorisées à l'aide de la méthode MoSCoW :

Ce format montre ainsi en un coup d'œil ce que l'équipe va livrer, mais aussi ce qui est délibérément repoussé pour une prochaine version.

5. Affiner et valider avant de développer

Cette étape s'appelle le backlog refinement (ou "grooming"). Elle consiste à revoir les prochains éléments avec l'équipe pour vérifier qu'ils sont suffisamment clairs et réalisables. C'est aussi à ce moment que sont posés les critères d'acceptation, aussi appelés Definition of Done (DoD) : ce sont les conditions précises qui permettront de dire qu'un élément est terminé.

6. Mettre à jour régulièrement le backlog

Un product backlog n'est jamais figé. Le revoir à intervalle régulier évite qu'il ne devienne une liste d'éléments obsolète qui gonfle sans jamais être nettoyée.

Questions fréquentes sur le product backlog