Fiche 11 : Le product backlog

LISTE DES BESOINS ET DEMANDES D'UN PRODUCT OWNER

En résumé

Scrum utilise une approche fonctionnelle pour récolter les besoins des utilisateurs. L'objectif est d'établir une liste de fonctionnalités à réaliser, que l'on appelle product backlog (carnet du produit).

À chaque élément du carnet sont associés 3 attributs : une description, une estimation et un ordre de priorité, qui est défini par le propriétaire du produit. Il peut changer cet ordre en cours de projet et même ajouter, modifier ou supprimer des éléments dans le carnet.

Pourquoi l'utiliser ?

Objectif

• Transformer l'intention de départ du projet en " commande " explicite.
• Lister les fonctionnalités à produire dans le cadre du projet, et les hiérarchiser.
• Faciliter la planification des releases et des sprints.

Contexte

Le backlog est construit dans sa forme initiale au démarrage du projet, avant le démarrage du premier sprint. Il va permettre la planification de la release (organisation de la livraison des stories et du périmètre des différents sprints). Il est ensuite mis à jour à chaque sprint.

C'est le product owner qui en est le garant (contenu et hiérarchisation des stories), mais c'est un outil qui est partagé avec l'ensemble des contributeurs de l'équipe et des parties prenantes du projet.

Comment l'utiliser ?

Étapes

• Faire " émerger " le backlog au démarrage du projet. Il est assez rare que le backlog initial intègre les (plus ou moins) 50 stories dont il sera constitué en cours de projet. Ceci est dû au fait que le product owner et les utilisateurs du projet disposent rarement d'un panorama exhaustif des fonctionnalités à livrer.
• Choisir le mode de représentation du backlog. Avant tout, le backlog est une liste de stories, mais ces dernières peuvent être représentées de 2 manières différentes :
  • des cartes sous format fiches bristol, rangées par ordre de priorité ;
  • sous format informatique, à l'aide d'un outil de gestion de backlog.
• Décrire les premières stories, en distinguant notamment les user stories, les stories techniques et les défauts.
• Définir les priorités entre les différentes stories : elles vont conditionner l'ordre dans lequel les stories seront développées (les plus prioritaires en premier !). Si toute l'équipe est associée à la définition des priorités, c'est le product owner qui dispose du dernier mot, car il est le garant du backlog.
• Intégrer les modifications progressives : tant que le produit du projet évolue, le backlog évolue ! Des stories peuvent être ajoutées ou supprimées, certaines peuvent être décomposées, et les priorités entre stories peuvent être revues. Ces changements peuvent être quotidiens, en fonction du feedback sur ce qui a été développé la veille, mais les changements majeurs interviennent lors des réunions de revue de sprint et de planification du sprint suivant.

Méthodologie et conseils

• Il est conseillé que le product owner soigne le backlog " aux petits oignons " : il doit s'assurer régulièrement qu'il est complet, en ajoutant de nouvelles stories ou en en supprimant, et que les stories sont bien priorisées.
• Le product owner raffine également progressivement ses stories en cours de projet, en décomposant les stories de grande taille en plusieurs stories de petites tailles.
• Attention de ne pas surcharger le backlog avec trop de stories (pas plus de 50), qui rendent difficile la compréhension globale du projet.