Le Product Backlog est une liste ordonnée et évolutive de tous les travaux jugés nécessaires par le Product Owner pour créer, publier, maintenir et entretenir un produit.
Chaque Produit a un et un seul Product Backlog, géré par un et un seul Product Owner.
Un Product Backlog est en évolution constante, grâce au feedback fourni par les parties prenantes au fil du temps et en Sprint Review.
Un Product Backlog existe jusqu’au retrait du Produit du marché.
Pour rendre transparent le Product Backlog, le Product Owner veillera, entre autres, à :
- Ordonnancer son contenu : de telle sorte qu’il reflète sa vision
- Rendre le contenu du Product Backlog accessible à tous dans l’entreprise
- Assurer une compréhension partagée du contenu Product Backlog. Souvent, par exemple, chaque élément du Product Backlog aura les informations suivantes : un titre, une description, des critères d’acceptation, une valeur métier, une estimation de complexité.
Adaptation du Product Backlog
L’adaptation du Product Backlog est fondamentale pour maximiser la valeur délivrée, mais en quoi consiste exactement cette adaptation ?
- Ré-ordonnancement du contenu, suite au feedback des parties prenantes en Sprint Review et au fil du temps
- Ajout de nouvelles idées
- Retrait d’idées passées qui ne correspondent plus à la vision (et n’ont plus de valeur)
- Toute autre action qui permet de rendre le Product Backlog correctement ordonnancé
La valeur est le seul critère pour ordonnancer le Product Backlog ?
Non. En effet, la valeur est un concept subjectif. Le Product Owner ordonnance le Product Backlog en discutant avec les parties prenantes. D’autres paramètres sont à prendre en compte pour ordonnancer le Product Backlog comme, par exemple :
- La valeur métier : le problème le plus urgent à résoudre pour les utilisateurs, une contrainte réglementaire, une fonctionnalité qu’aucun concurrent possède, etc.
- Le risque : en Scrum le risque ne se gère pas, il est traité en premier. Cela a un impact sur l’ordonnancement
- La taille de l’élément du Product Backlog : les éléments de plus haute valeur auront une taille jugée par l’équipe de développement comme réalisable en un Sprint
En aucun cas, l’ordonnancement est dicté par la difficulté de réalisation. Le Product Owner prend en compte l’avis de l’équipe de développement, sans pour autant faire un focus sur « le facile à faire » d’abord, car cela ne correspond pas à la maximisation de la valeur.
Quel niveau de détails doit avoir un élément du Product Backlog
Un niveau suffisant pour permettre à tous de comprendre et se souvenir du sujet à discuter, le jour venu.
Souvenez-vous d’un des quatre principes de l’Agile Manifesto : « les individus et leurs interactions plus que le processus et les outils ». Il s’agit de marquer l’idée dès qu’elle se présente et en suite la développer au moment ou elle devient « prioritaire ».
Nul besoin de passer des heures à écrire des spécifications détaillées, car cela serait une perte de temps et d’énergies qui pourraient être consacrées à des sujets à valeur immédiate pour les utilisateurs.
On privilégiera la collaboration de toutes les personnes compétentes sur le sujet, au moment opportun.
Vous souhaitez aller plus loin au sujet des estimations et de la planification Agile ? Le livre « Agile Estimating and Planning » de Mike Cohn est un bon début.
Téléchargez et imprimez (en A4 ou A3) le poster relatif à cet article, il pourra vous être utile au bureau, les QR codes permettent d’approfondir les sujets proposés !
Cet article fait partie d’une série de douze publications, chacune expliquant les bases de Scrum. Il pourra vous être utile comme présentation auprès du management, ou toutes personnes curieuses d’approfondir le sujet.