Backlog produit : comment le construire et le prioriser efficacement
Le product backlog est le moteur du développement agile. Chaque fonctionnalité, correction de bug, amélioration et tâche technique susceptible d’être développée y figure, classée par priorité, dimensionnée pour l’estimation et prête à être intégrée dans un sprint.
Un backlog bien géré est l’un des signes les plus clairs de la maturité d’une équipe agile. Un backlog négligé — composé de centaines d’éléments, souvent non pertinents, aux priorités floues et sans estimations — est l’un des signes les plus évidents que le processus de l’équipe nécessite une attention particulière.
Ce guide explique comment construire un product backlog à partir de zéro, comment le maintenir et comment s’assurer qu’il stimule réellement le développement au lieu de devenir un dépotoir d’idées non géré.
Qu’est-ce qu’un Product Backlog ?
Dans Scrum, le product backlog est une liste ordonnée de tout ce qui pourrait être fait pour améliorer le produit. Il est la propriété du Product Owner et constitue la source unique de vérité concernant le travail de l’équipe.
Le backlog contient :
- User stories — fonctionnalités décrites du point de vue de l’utilisateur
- Corrections de bugs — défauts à résoudre
- Dette technique — améliorations de la qualité du code, de l’architecture ou de l’infrastructure
- Spikes — tâches de recherche visant à réduire l’incertitude avant de s’engager sur une fonctionnalité
- Exigences non fonctionnelles — améliorations liées à la performance, à la sécurité ou à l’accessibilité
Chaque élément du backlog doit y figurer pour une raison précise : il représente une valeur potentielle pour les utilisateurs ou l’entreprise. Les éléments qui ne représentent plus de valeur doivent être supprimés, et non simplement dépriorisés.
Le rôle du Product Owner
Le Product Owner (PO) est responsable du backlog. Cela implique :
- Ajouter de nouveaux éléments dès qu’ils sont identifiés
- Supprimer les éléments qui ne sont plus pertinents
- Maintenir le backlog classé par priorité à tout moment
- S’assurer que le haut du backlog est prêt à être traité par l’équipe de développement
Le PO ne crée pas le backlog de manière isolée. Il reçoit des contributions des utilisateurs, des parties prenantes, des développeurs et des données. Cependant, le PO prend la décision finale concernant la priorité.
Ce modèle à propriétaire unique est l’un des principes les plus importants de l’agilité. Les backlogs gérés par comité ou par vote ont tendance à privilégier le compromis plutôt qu’une hiérarchisation claire, ce qui conduit les équipes à travailler sur tout en même temps.
Rédiger de bons éléments de backlog
"User can export data"
"As a user I can filter"
"Add pagination to list"
Format de User Story
Le format standard d’une user story est :
En tant que [type d’utilisateur], je veux [action] afin de [bénéfice].
Exemple : “En tant que chef de projet, je veux filtrer les tâches par responsable afin de voir la charge de travail de mon équipe en un coup d’œil.”
Ce format vous oblige à articuler qui en bénéficie, ce dont ils ont besoin et pourquoi — trois éléments de contexte qui évitent de développer des fonctionnalités pour les mauvaises raisons.
Critères d’acceptation
Chaque élément du backlog doit avoir des critères d’acceptation : des conditions spécifiques et testables qui doivent être remplies pour que l’élément soit considéré comme terminé.
Exemple de critères d’acceptation pour la story de filtrage :
- Les utilisateurs peuvent filtrer par un ou plusieurs responsables simultanément
- La vue filtrée se met à jour en temps réel sans rechargement de page
- L’état du filtre est conservé lorsque l’utilisateur quitte la page et y revient
- Les tâches non assignées apparaissent lorsque “Non assigné” est sélectionné
Sans critères d’acceptation, le terme “terminé” est indéfini. Avec eux, le développeur et le testeur savent exactement ce qu’ils doivent vérifier.
Critères INVEST
Les bonnes user stories respectent les critères INVEST :
| Lettre | Signification |
|---|---|
| I | Indépendant — peut être développé sans dépendre d’une autre story |
| N | Négociable — les détails peuvent être ajustés lors des discussions |
| V | Valorisable — apporte de la valeur aux utilisateurs ou à l’entreprise |
| E | Estimable — l’équipe peut estimer l’effort requis |
| S | Small (Petit) — peut être complété en un seul sprint |
| T | Testable — possède des critères d’acceptation clairs |
Les stories qui ne respectent pas ces critères — généralement parce qu’elles sont trop grandes, trop vagues ou non livrables indépendamment — doivent être affinées avant d’entrer dans un sprint.
Techniques de priorisation du backlog
La priorisation est le point de rencontre entre le jugement produit et les données. Plusieurs cadres offrent une structure pour prendre des décisions de priorisation.
Méthode MoSCoW
Classez chaque élément en Must have (doit avoir), Should have (devrait avoir), Could have (pourrait avoir) ou Won’t have (ne sera pas fait pour cette version). Cela crée un système de priorité simple à quatre niveaux que les parties prenantes peuvent comprendre et utiliser.
Scoring RICE
RICE signifie Reach (portée), Impact, Confidence (confiance), Effort. Chaque élément est noté sur ces dimensions et classé selon le score RICE : (Portée × Impact × Confiance) / Effort.
Il s’agit d’une priorisation quantitative — elle fonctionne bien lorsque vous disposez de données sur la portée et l’impact et que vous souhaitez un classement plus défendable qu’une simple intuition.
Matrice Valeur vs Effort
Placez chaque élément du backlog sur une matrice 2x2 : la valeur sur un axe, l’effort sur l’autre. Les éléments dans le quadrant “haute valeur, faible effort” sont des gains rapides et doivent être priorisés. Les éléments dans le quadrant “faible valeur, fort effort” sont des candidats à la suppression.
Modèle de Kano
Le modèle de Kano classe les fonctionnalités selon leur impact sur la satisfaction des utilisateurs :
- Besoins de base — leur absence cause de l’insatisfaction ; leur présence est attendue (must-haves)
- Besoins de performance — plus il y en a, mieux c’est (fonctionnalités principales)
- Delighters (éléments de plaisir) — fonctionnalités inattendues qui augmentent considérablement la satisfaction
Ce cadre aide à équilibrer les must-haves avec l’innovation.
Grooming (Affinage) du backlog
Le grooming du backlog — également appelé affinage du backlog — est le processus récurrent consistant à examiner, mettre à jour et améliorer les éléments du backlog. Dans Scrum, cela se produit généralement une fois par sprint lors d’une réunion dédiée.
Une session de grooming comprend :
- L’examen des nouveaux éléments — éléments ajoutés depuis le dernier grooming. Sont-ils écrits clairement ? Ont-ils des critères d’acceptation ?
- L’estimation des éléments — les équipes estiment l’effort pour les éléments situés en haut du backlog afin qu’ils soient prêts pour la planification du sprint.
- Le découpage des éléments volumineux — les epics et les grosses stories sont décomposées en éléments plus petits, adaptés à la taille d’un sprint.
- L’élagage — suppression des éléments qui ne sont plus pertinents, obsolètes ou en double.
- La re-priorisation — ajustement de l’ordre en fonction de nouvelles informations, des retours des parties prenantes ou de l’évolution des priorités commerciales.
Un rythme de grooming sain signifie que le haut de votre backlog est toujours prêt — écrit, estimé et priorisé — pour le prochain sprint.
Maintenir un backlog sain
Un backlog qui croît indéfiniment sans élagage devient un fardeau. Les équipes cessent de lui faire confiance car elles savent qu’il est rempli d’éléments que personne n’a l’intention de développer. Voici les signes d’un backlog sain et comment les maintenir.
Signes d’un backlog sain
- Les dix à quinze premiers éléments sont affinés et prêts pour un sprint
- Tous les éléments ont des titres clairs et des critères d’acceptation
- Le backlog ne contient aucun élément vieux de plus de six mois qui n’a jamais été priorisé en haut de liste
- Chaque membre de l’équipe a lu le haut du backlog récemment
- Les éléments sont régulièrement supprimés, pas seulement ajoutés
La règle du “Si ce n’est pas développé dans les six mois, supprimez-le”
De nombreuses équipes conservent des centaines d’éléments de backlog qu’elles n’ont aucune intention de développer dans les six prochains mois. Cela crée un bruit qui rend les vraies priorités plus difficiles à identifier. Une règle utile : si un élément est resté dans le tiers inférieur du backlog pendant six mois, archivez-le ou supprimez-le. S’il est important, il refera surface.
Séparez la “glacière” (Icebox)
Certaines équipes maintiennent une “glacière” — une collection séparée d’idées et de travaux futurs potentiels qui ne font explicitement pas partie du backlog actif. Les éléments dans la glacière ne sont ni priorisés, ni affinés, ni estimés. Ils sont simplement capturés pour une considération future.
Cela évite que la glacière ne pollue le backlog actif et rend ce dernier plus petit, plus propre et plus fiable.
Product Backlog vs Sprint Backlog
Le product backlog et le sprint backlog sont liés mais distincts :
| Product Backlog | Sprint Backlog | |
|---|---|---|
| Portée | Tout ce qui pourrait être construit | Ce sur quoi l’équipe s’engage pour ce sprint |
| Propriétaire | Product Owner | Équipe de développement |
| Durée | Continue, évolutive | Un sprint (1 à 4 semaines) |
| Niveau de détail | Variable (haut = détaillé, bas = approximatif) | Tous les éléments sont entièrement affinés |
| Taille | Potentiellement des centaines d’éléments | Généralement 10 à 20 éléments |
Lors de la planification du sprint, l’équipe extrait des éléments du haut du product backlog vers le sprint backlog. C’est pourquoi le haut du product backlog doit toujours être prêt : la réunion de planification du sprint ne peut pas affiner les stories en temps réel pour tout le sprint.
Lectures associées : Sprint Planning : Comment mener une session efficace et Guide de User Story Mapping
Outils pour gérer un Product Backlog
| Outil | Idéal pour | Fonctionnalités de backlog | Prix |
|---|---|---|---|
| Jira | Grandes équipes d’ingénierie | Epics, stories, sprints, reporting | $7.75/utilisateur/mois |
| Linear | Équipes d’ingénierie produit | UI épurée, cycles, roadmaps | Gratuit / $8/mois |
| TasksBoard | Équipes Google Workspace | Kanban, listes de tâches partagées | Gratuit / Premium |
| Notion | Équipes flexibles | Bases de données personnalisées, vues | Gratuit / $8/mois |
| Trello | Petites équipes | Cartes, listes, étiquettes | Gratuit / $5/mois |
| Asana | Équipes transversales | Portefeuilles, timelines, charge de travail | Gratuit / $10.99/mois |
Pour les équipes qui utilisent Google Workspace, TasksBoard offre un moyen simple de gérer les éléments du backlog sous forme de listes Google Tasks partagées avec une vue en tableau kanban — sans la lourdeur d’une plateforme de gestion de projet dédiée.
FAQ
Qui possède le product backlog ?
Le Product Owner possède le backlog et est responsable de son contenu, de son ordre et de sa disponibilité. L’équipe de développement contribue aux estimations et aux apports techniques, mais le PO prend les décisions finales de priorisation.
À quelle fréquence le backlog doit-il être groomé ?
La plupart des équipes Scrum effectuent un grooming une fois par sprint, en consacrant environ 10 % de leur capacité de sprint à l’affinage. Pour un sprint de deux semaines, cela représente environ 90 minutes par semaine.
Quelle doit être la taille d’un product backlog ?
Il n’y a pas de réponse universelle, mais un backlog de plus de 100 éléments est souvent le signe que les anciens éléments ne sont pas élagués. Concentrez-vous sur le maintien des 20 à 30 premiers éléments affinés et prêts ; le reste peut être moins détaillé.
Qu’est-ce qu’une epic dans le contexte d’un product backlog ?
Une epic est une grande user story trop volumineuse pour être terminée en un seul sprint. Les epics sont décomposées en stories plus petites lors de l’affinage du backlog. Elles servent de conteneurs d’organisation pour les fonctionnalités connexes.
Comment gérez-vous les bugs dans le product backlog ?
Les bugs sont traités comme des éléments de backlog et priorisés par rapport aux fonctionnalités. Les bugs critiques sautent généralement en haut de la liste ; les bugs cosmétiques mineurs peuvent se situer en dessous de nombreuses fonctionnalités. Certaines équipes maintiennent une liste de bugs séparée et la fusionnent avec le backlog uniquement au moment de la priorisation.
Quelle est la différence entre un product backlog et une roadmap ?
Une roadmap communique les fonctionnalités prévues et les délais aux parties prenantes à un haut niveau. Un backlog est la liste opérationnelle interne des travaux priorisés pour le développement. Les roadmaps sont dérivées des backlogs mais présentent une vue simplifiée et limitée dans le temps, adaptée aux audiences externes.
Gérez votre backlog avec TasksBoard
Un product backlog n’est utile que si l’équipe peut le voir, le mettre à jour et lui faire confiance. TasksBoard transforme les listes Google Tasks partagées en un tableau kanban visuel — offrant à votre équipe un moyen simple et collaboratif de gérer les éléments du backlog sans configuration complexe.
Créez des listes pour vos étapes de backlog (Icebox, Backlog, En cours, Terminé), ajoutez des tâches avec des descriptions et des dates d’échéance, et partagez le tableau avec toute l’équipe. C’est le chemin le plus court entre “que construisons-nous ensuite ?” et une réponse claire et partagée.
Prêt à partager vos Google Tasks ?
Commencez avec TasksBoard gratuitement, aucune carte de crédit requise.
Se connecter
