9 – Artefacts Scrum : Product Backlog

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é.
Product Backlog
Product Backlog

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.

Agile Estimating and Planning
Agile Estimating and Planning

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.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.