Guide Scrum · Artefacts et pratiques
Le Product Backlog dans Scrum : définition et gestion
Le Product Backlog est une liste émergente et ordonnée de ce qui est nécessaire pour améliorer le produit. Dans Scrum, c'est l'unique source du travail entrepris par la Scrum Team, et son engagement est le Product Goal.
À retenir
- Le Product Backlog est une liste émergente et ordonnée, et l'unique source de travail de la Scrum Team.
- Le Product Owner en est responsable ; les Developers estiment la taille des éléments.
- Son engagement est le Product Goal, qui donne une direction au backlog.
- Gardez-le court, ordonné et affiné dans sa partie haute, et supprimez les éléments qui n'apportent plus de valeur.
Ce qu'est le Product Backlog
Le Product Backlog est l'un des trois artefacts Scrum, ainsi que le Sprint Backlog et le Increment. Il contient tout ce que la Scrum Team estime actuellement susceptible d'apporter de la valeur au produit : nouvelles fonctionnalités, modifications, corrections, travail technique, recherches et expérimentations.
- Émergent : il n'est jamais terminé. Des éléments sont ajoutés, modifiés et supprimés à mesure que l'équipe et les parties prenantes apprennent.
- Ordonné : les éléments ont un ordre clair, de sorte que chacun voit ce qui sera traité ensuite. Le Guide Scrum 2020 parle d'éléments ordonnés plutôt que priorisés, car l'ordre peut refléter la valeur, le risque, les dépendances et l'apprentissage autant que la priorité.
- Source unique de travail : si la Scrum Team doit y travailler, cela doit être visible dans le Product Backlog.
- Un par produit : plusieurs Scrum Teams travaillant sur le même produit partagent un seul Product Backlog et un seul Product Owner.
À qui appartient le Product Backlog
Le Product Owner est responsable de la gestion efficace du Product Backlog. Selon le Guide Scrum 2020, cela comprend :
- Élaborer le Product Goal et le communiquer explicitement.
- Créer les éléments du Product Backlog et les communiquer clairement.
- Ordonner les éléments du Product Backlog.
- Veiller à ce que le Product Backlog soit transparent, visible et compris.
Le Product Owner peut demander à d'autres de réaliser une partie de ce travail, mais il en reste responsable. Les Developers qui réaliseront le travail sont chargés d'estimer la taille des éléments, et le Scrum Master aide le Product Owner à trouver des techniques efficaces de gestion du backlog. Toute personne qui souhaite modifier le Product Backlog doit pour cela convaincre le Product Owner.
Le Product Goal
Le Product Goal décrit un état futur du produit vers lequel la Scrum Team planifie son travail. Il se trouve dans le Product Backlog, et le reste du Product Backlog émerge pour définir ce qui permettra de l'atteindre. L'équipe doit atteindre ou abandonner un Product Goal avant de passer au suivant.
| Niveau | Engagement | Exemple |
|---|---|---|
| Product Backlog | Product Goal | Les clients peuvent gérer l'ensemble de leur compte en ligne sans appeler le support |
| Sprint Backlog | Sprint Goal | Les clients peuvent télécharger leurs anciennes factures en PDF |
| Increment | Definition of Done | Code relu, testé, accessible et déployé en production |
Ce que contient un élément du Product Backlog
Le Guide Scrum n'impose pas de format. Les attributs varient selon le domaine de travail, mais la plupart des équipes consignent :
| Attribut | Finalité |
|---|---|
| Description | Ce qui est nécessaire et pourquoi ; souvent rédigé sous forme de user story |
| Ordre | Sa position par rapport aux autres éléments |
| Taille | Une estimation des Developers, par exemple en story points |
| Critères d'acceptation | Conditions qui confirment que l'élément fait ce qu'il doit faire |
| Valeur ou justification | Le résultat ou le bénéfice attendu |
| Notes et liens | Maquettes, recherches, dépendances ou epics |
Les éléments du haut sont petits, clairs et détaillés. Ceux situés plus bas peuvent être plus gros et plus flous, car les détails ajoutés trop tôt sont souvent du travail perdu. Les éléments qui peuvent être Done en un seul Sprint sont considérés comme prêts à être sélectionnés lors du Sprint Planning.
Comment gérer un Product Backlog, étape par étape
- Formulez par écrit le Product Goal et partagez-le avec l'équipe et les parties prenantes.
- Consignez les idées, les demandes et le travail connu sous forme d'éléments, sans vous soucier des détails pour l'instant.
- Ordonnez les éléments en tenant compte de la valeur, du risque, du coût, des dépendances et de ce que l'équipe doit apprendre.
- Affinez régulièrement le haut du backlog pour que les éléments des un ou deux prochains Sprints soient clairs et estimés ; voir affinage du backlog.
- Utilisez la Sprint Review pour inspecter l'avancement avec les parties prenantes et adapter le backlog.
- Supprimez les éléments qui ne servent plus le Product Goal, afin que le backlog reste court et utile.
- Suivez l'avancement vers le Product Goal avec un burnup chart ou une prévision ; voir Indicateurs Scrum.
Exemple pratique : ordonner un petit backlog
Le Product Owner d'un service de réservation en ligne a pour Product Goal « Les clients peuvent prendre et modifier leurs rendez-vous sans nous appeler ». Les Developers ont estimé la taille des éléments. Le Product Owner les ordonne en mettant en balance la valeur, la taille et le risque :
| Ordre | Élément | Taille (points) | Raison de sa position |
|---|---|---|---|
| 1 | Prendre rendez-vous en ligne | 8 | Au cœur du Product Goal ; rien d'autre n'est utile sans lui |
| 2 | E-mail de confirmation après réservation | 3 | Forte valeur, petite taille, réduit les absences |
| 3 | Modifier ou annuler une réservation | 5 | Réduit directement les appels téléphoniques |
| 4 | Spike : intégration avec le fournisseur d'agenda | 2 | Réduit le risque avant l'élément 5 |
| 5 | Synchroniser les réservations avec les agendas du personnel | 8 | Utile mais dépend des enseignements du spike |
| 6 | Codes de réduction fidélité | 13 | Pas nécessaire pour le Product Goal actuel |
Si la vélocité de l'équipe est d'environ 15 points, les éléments 1 à 3 (16 points) dépassent légèrement un Sprint : l'équipe pourrait donc planifier les éléments 1 et 2 ainsi que le spike, puis prendre l'élément 3 au Sprint suivant. L'élément 6 peut être supprimé ou mis de côté jusqu'à un Product Goal ultérieur.
Product Backlog vs Sprint Backlog
| Product Backlog | Sprint Backlog | |
|---|---|---|
| Contenu | Tout ce qui pourrait améliorer le produit | Sprint Goal, éléments sélectionnés et plan |
| Approbateur (Accountable) | Product Owner | Developers |
| Engagement | Product Goal | Sprint Goal |
| Horizon temporel | La durée de vie du produit | Un Sprint |
| Ce qui change | Chaque fois que le Product Owner réordonne ou ajoute des éléments | Chaque jour, à mesure que les Developers apprennent |
Erreurs courantes
- Un backlog qui ne fait que grossir. Des centaines d'anciens éléments masquent ce qui compte. Supprimez ou archivez les éléments qui ne servent plus le Product Goal.
- Plusieurs backlogs pour un même produit. Des backlogs d'équipe séparés rendent impossible l'ordonnancement à l'échelle du produit.
- Tout est « haute priorité ». L'ordre est une séquence stricte, pas un ensemble d'étiquettes.
- Trop de détails trop tôt. Les spécifications détaillées d'éléments prévus dans plusieurs mois sont généralement réécrites.
- Le Product Owner travaille seul. L'affinage fonctionne mieux en collaboration avec les Developers et les parties prenantes.
- Pas de Product Goal. Sans lui, le backlog devient une liste de demandes plutôt qu'un plan de création de valeur.
Modèles gratuits sur ce sujet
Questions fréquentes
Qu'est-ce qu'un Product Backlog dans Scrum ?
C'est une liste émergente et ordonnée de ce qui est nécessaire pour améliorer le produit, et l'unique source de travail de la Scrum Team. Son engagement est le Product Goal.
À qui appartient le Product Backlog ?
Le Product Owner en est responsable. D'autres personnes peuvent y contribuer et être sollicitées pour une partie du travail, mais c'est le Product Owner qui décide de l'ordre.
Qui peut ajouter des éléments au Product Backlog ?
Tout le monde peut proposer des éléments, et dans de nombreuses équipes les Developers en ajoutent directement. Le Product Owner reste responsable du contenu et de l'ordre.
Quelle est la différence entre un Product Backlog priorisé et un Product Backlog ordonné ?
Prioriser consiste souvent à étiqueter les éléments en priorité haute, moyenne ou basse. Ordonner consiste à placer chaque élément dans une séquence unique, qui peut refléter la valeur, le risque, les dépendances et l'apprentissage.
Quel est le lien entre le Product Goal et le Product Backlog ?
C'est l'engagement associé au Product Backlog : un état futur du produit vers lequel la Scrum Team planifie son travail. L'équipe travaille sur un seul Product Goal à la fois.
Quelle taille doit avoir un Product Backlog ?
Il n'y a pas de règle. Un backlog trop long pour être lu et ordonné devient difficile à gérer : de nombreuses équipes limitent donc les éléments détaillés à quelques Sprints et conservent le reste sous forme d'éléments plus gros et moins précis.
Les éléments du Product Backlog doivent-ils être des user stories ?
Non. Le Guide Scrum n'impose pas de format. Les user stories sont populaires, mais les éléments peuvent aussi être des bugs, des tâches techniques, des expérimentations ou de simples descriptions.
Qui estime les éléments du Product Backlog ?
Les Developers qui réaliseront le travail sont responsables de l'estimation. Le Product Owner peut les aider à comprendre les éléments et les arbitrages.
Quand un élément du Product Backlog est-il prêt ?
Le Guide Scrum indique que les éléments pouvant être Done en un seul Sprint sont considérés comme prêts à être sélectionnés lors du Sprint Planning. Certaines équipes ajoutent une Definition of Ready facultative.
Plusieurs équipes peuvent-elles partager un même Product Backlog ?
Oui. Dans Scrum, un produit a un seul Product Backlog et un seul Product Owner, même lorsque plusieurs équipes y travaillent.
Le Product Backlog est-il la même chose qu'un plan de projet ?
Non. C'est une liste évolutive pour le produit plutôt qu'un plan figé, même si elle peut être utilisée avec des prévisions et un plan de release.
Quels outils puis-je utiliser pour un Product Backlog ?
Tout ce qui va d'un tableur ou de post-it à des outils comme Jira ou Trello. Voir Outils logiciels Scrum.