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 se trouve dans le backlog, classée par priorité, évaluée pour 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é contenant des centaines d’éléments, dont beaucoup sont non pertinents, avec des priorités floues et aucune estimation, est l’un des signes les plus évidents que le processus de l’équipe nécessite une attention particulière.
Ce guide explique comment créer un product backlog à partir de zéro, comment le maintenir et comment s’assurer qu’il pilote réellement le développement plutôt que de rester 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
- Bug fixes : défauts à résoudre
- Technical debt : 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é
- Non-functional requirements : améliorations des performances, de la sécurité ou de 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 de :
- 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 sur 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 tendent vers le compromis plutôt que vers une priorisation claire, et les équipes finissent par 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 des User Stories
Le format standard d’une user story est :
En tant que [type d’utilisateur], je veux [une action] afin de [un 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. Ces trois éléments de contexte empêchent de créer 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é” n’est pas dé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 de la discussion |
| V | Valeur : 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 sprint |
| T | Testable : possède des critères d’acceptation clairs |
Les stories qui ne respectent pas ces critères doivent être affinées avant d’entrer dans un sprint. Cela arrive généralement lorsqu’elles sont trop grandes, trop vagues ou non livrables indépendamment.
Techniques de priorisation du backlog
La priorisation est le point de rencontre entre le jugement produit et les données. Plusieurs cadres fournissent 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é par 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 Kano
Le modèle Kano classe les fonctionnalités selon leur impact sur la satisfaction des utilisateurs :
- Besoins de base : leur absence provoque l’insatisfaction. Leur présence est attendue (indispensables)
- Besoins de performance : plus il y en a, mieux c’est (fonctionnalités principales)
- Enchanteurs : fonctionnalités inattendues qui augmentent considérablement la satisfaction
Ce cadre aide à équilibrer les indispensables avec l’innovation.
Grooming du backlog (Affinement)
Le grooming du backlog, également appelé affinement du backlog, est le processus récurrent de révision, de mise à jour et d’amélioration des é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 :
- Révision des nouveaux éléments : éléments ajoutés depuis le dernier grooming. Sont-ils rédigés clairement ? Ont-ils des critères d’acceptation ?
- Estimation des éléments : les équipes estiment l’effort pour les éléments en haut du backlog afin qu’ils soient prêts pour la planification du sprint.
- Décomposition des gros éléments : les epics et les grandes stories sont décomposées en éléments plus petits, adaptés à la taille d’un sprint.
- Élagage : suppression des éléments qui ne sont plus pertinents, obsolètes ou en double.
- Repriorisation : ajustement de l’ordre en fonction de nouvelles informations, des retours des parties prenantes ou de changements dans les priorités commerciales.
Un rythme de grooming sain signifie que le haut de votre backlog est toujours prêt pour le prochain sprint : rédigé, estimé et priorisé.
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 “Si ce n’est pas développé dans 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 à voir. 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éparer 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 empêche la glacière de polluer 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 | Continu, évolutif | Un sprint (1 à 4 semaines) |
| Niveau de détail | Variable (haut = détaillé, bas = brut) | 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.
Lecture associée : 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/user/mo |
| Linear | Équipes d’ingénierie produit | UI épurée, cycles, roadmaps | Gratuit / $8/mo |
| 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/mo |
| Trello | Petites équipes | Cartes, listes, étiquettes | Gratuit / $5/mo |
| Asana | Équipes interfonctionnelles | Portfolio, timelines, charge de travail | Gratuit / $10.99/mo |
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’affinement. 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 importante pour être terminée en un seul sprint. Les epics sont décomposées en stories plus petites lors de l’affinement du backlog. Elles servent de conteneurs d’organisation pour les fonctionnalités associées.
Comment gérez-vous les bugs dans le product backlog ?
Les bugs sont traités comme des éléments du 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 du travail priorisé 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 (Glacière, 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
