Le backlog de produit

18 dimanche janvier 2009 22:40

Les équipes agiles ne produisent pas une documentation faite au début du projet, qui décrit en détail toutes les spécifications fonctionnelles. Elles collectent les fonctions essentielles (les features) et les raffinent progressivement. Il n'y a pas un gros document de spécification, l'outil de collecte s'appelle le backlog de produit.

Objectif

Le backlog de produit est la liste des fonctionnalités attendues d'un produit. Plus exactement, au-delà de cet aspect fonctionnel, il contient tous les éléments qui vont nécessiter du travail pour l'équipe. Les éléments y sont classés par priorité ce qui permet de définir l'ordre de réalisation.

Rôles

Le backlog de produit est sous la responsabilité du product owner. Chacun peut contribuer à collecter des éléments, mais c'est le product owner qui les accepte finalement et c'est lui qui définit les priorités.

Utilisation

Le backlog est élaboré avant le lancement des sprints, dans la phase de préparation (ou sprint 0). Il est utilisé pour planifier la release, puis à chaque sprint, lors de la réunion de planification du sprint pour décider du sous-ensemble qui sera réalisé.

C'est donc un outil essentiel pour la planification. Mais il est aussi, par sa nature, un maillon de la gestion des exigences, puisqu'on y collecte ce que doit faire le produit.

A tout moment, le backlog est visible par tout le monde.

Vie du backlog

Le backlog pour un produit peut avoir une durée de vie longue, équivalente à celle du produit. Ce n'est pas un document figé, il est toujours vivant. Des éléments sont ajoutés, des éléments sont supprimés, des éléments sont décomposés ou les priorités ajustées. Il est courant que le backlog soit modifié quotidiennement dans un projet, c'est l'outil de base du product owner, mais il subit les modifications les plus importantes lors du passage au sprint suivant.

Produits dérivés

Le backlog de produit permet de produire le planning de release, c'est à dire le sous-ensemble des éléments du backlog qu'on estime finir pour la date prévue de release.
Le backlog de produit permet de produire le burndown chart de release, qui est un graphe, mis à jour à la fin de chaque sprint, montrant la tendance de l'avancement dans la réalisation des éléments du backlog de produit.

Exemple de backlog de produit

Backlog de produit

Erreurs à éviter

  • ne pas avoir de backlog de produit
  • avoir plusieurs backlogs pour un seul produit (ou d'autres sources parasites, comme un bugtracker)
  • ne pas partager le backlog avec toute l'équipe
  • ne pas faire vivre le backlog pendant le projet
  • confondre avec le backlog de sprint en y mettant des tâches
  • avoir plus de 150 éléments à faire dans le backlog

Commentaires

1. Le 19 lundi janvier 2009, 20:56 par david

d'ou vient la limite de 150 ?

Mon expérience des backlogs, c'est qu'au delà de 100, ça devient compliqué à s'y retrouver pour un Product Owner . La limite de 150 est donnée par Mike Cohn.

et quelle en est la motivation profonde ?

un backlog trop gros est le signe d'une décomposition prématurée et devient ingérable par un Product Owner.

que préconiser comme démarche si on dépasse ce nombre ? ou est notre erreur ?

on appelle un consultant !

merci