The product backlog: your ultimate to-do list

Un backlog de produit robuste ressemble beaucoup à un individu sain : il est soigné, organisé et évolue dans un espace de liberté.

Dan Radigan Dan Radigan

S'il est correctement hiérarchisé, non seulement le backlog agile facilite la planification des livraisons et des itérations, mais il communique toutes les tâches sur lesquelles votre équipe a l'intention de travailler, y compris les tâches internes dont le client n'aura jamais connaissance. Cela permet de définir les attentes avec les parties prenantes et les autres équipes, en particulier lorsque celles-ci vous fournissent du travail supplémentaire. Il est possible également de définir le temps de développement comme un actif fixe.

Qu'est-ce qu'un backlog de produit ?

Un backlog produit est une liste priorisée de tâches destinées à l'équipe de développement. Il est créé à partir de la feuille de route et de ses exigences. Les éléments les plus importants figurent en tête du backlog produit. Ainsi, l'équipe sait ce qu'elle doit livrer en priorité. L'équipe de développement ne suit pas le backlog au rythme du responsable produit, et celui-ci n'impose pas de tâches à l'équipe de développement. Cette dernière récupère les tâches à réaliser dans le backlog produit en fonction de ses capacités, soit en continu (Kanban), soit par itération (Scrum).  

Pro Tip:

Conservez tout au sein d'un même outil de suivi des tickets. Évitez d'utiliser plusieurs systèmes pour suivre les bugs, les exigences et les tâches d'ingénierie. S'il s'agit de tâches pour l'équipe de développement, conservez-les dans un même backlog.

Pour commencer : feuille de route et exigences

La feuille de route et les exigences d'une équipe forment la base du backlog produit. Les initiatives de la feuille de route se décomposent en plusieurs epics. Chaque epic comporte plusieurs exigences et user stories. Examinons la feuille de route d'un produit fictif baptisé Teams in Space.

Feuille de route Agile | Atlassian – Le coach Agile

Comme le site Web de Teams in Space correspond à la première initiative de la feuille de route, nous allons décomposer cette initiative en epics (affichés ici en vert, bleu et bleu sarcelle) et user stories pour chacun de ces epics. 

Initiatives et epics Agile | Atlassian – Le coach Agile

Le responsable produit organise ensuite chacune des user stories en une liste unique pour l'équipe de développement. Il peut décider de fournir d'abord un epic complet (gauche). Ou alors, il peut être plus important pour le programme de tester la réservation d'un vol à tarif réduit qui nécessite les stories de plusieurs epics (droite). Observez les deux exemples ci-dessous. 

Epics et stories Agile | Atlassian – Le coach Agile

Quels sont les facteurs qui peuvent influencer le responsable produit dans la hiérarchisation ?

  • Priorité du client
  • Urgence d'obtenir un feedback
  • Difficultés relatives de la mise en œuvre
  • Relations symbiotiques entre les tâches (par exemple, B est plus facile si nous terminons A avant)

Bien que le responsable produit soit chargé de hiérarchiser le backlog, cela ne se fait pas dans l'absolu. Les responsables produit efficaces cherchent à recueillir les commentaires et le feedback des clients, des concepteurs et de l'équipe de développement afin d'optimiser l'ensemble des charges de travail et la livraison des produits. 

La garantie d'un backlog robuste

Une fois le backlog créé, il est important de l'actualiser régulièrement afin de l'adapter au programme. Les responsables produit doivent passer en revue le backlog avant chaque réunion de planification des itérations afin de s'assurer que la priorisation est correcte et que le feedback de la dernière itération a bien été intégré. La revue régulière du backlog est souvent appelée « préparation » dans les cercles Agile (certains parlent d'amélioration).

Au fur et à mesure que le backlog s'allonge, les responsables produit doivent le résumer en tâches à court terme et à long terme. Les tâches à court terme doivent être complètement définies avant d'être libellées comme telles. Cela signifie que des user stories complètes ont été rédigées, que la collaboration avec les équipes de conception et de développement a été organisée, et que l'équipe de développement a procédé à des estimations. Les tâches à plus long terme peuvent rester un peu vagues, même s'il est judicieux d'obtenir de l'équipe de développement une estimation approximative pour pouvoir les hiérarchiser. Le mot clé ici est « approximative » : ces estimations évolueront une fois que l'équipe aura parfaitement compris en quoi consiste ces tâches à plus long terme et commencé à travailler dessus.

Le backlog sert de lien entre le responsable produit et l'équipe de développement. Le responsable produit est libre de modifier à tout moment la hiérarchisation des tâches du backlog suite au feedback du client, à la révision des estimations ou à l'apparition de nouvelles contraintes. Une fois que la tâche est en cours, limitez les modifications car elles perturbent l'équipe de développement et jouent sur la concentration, le flux et le moral. 

Pro Tip:

Lorsque le backlog dépasse les capacités à long terme de l'équipe, les tickets que l'équipe ne traitera jamais peuvent parfaitement être clôturés. Signalez-les avec une résolution spécifique, par exemple « hors périmètre », dans l'outil de suivi de tickets, afin de faciliter les recherches ultérieures. 

Anti-schémas à surveiller

  • Le responsable produit hiérarchise le backlog au début du projet, mais ne l'adapte pas en fonction du feedback des développeurs et des parties prenantes.
  • L'équipe limite les tâches du backlog aux seules tâches qui concernent directement le client.
  • Le backlog est conservé sous forme de document stocké en local et peu partagé, ce qui empêche les parties concernées de se tenir informées.

Le backlog de produit au service de l'agilité de l'équipe

Les responsables produit avisés soignent rigoureusement le backlog de produit de leur programme. Ils y font une description fiable des tâches d'un projet et en facilitent le partage.

Les parties prenantes remettront en question les priorités. Et c'est une bonne chose. Encourager la discussion autour des aspects importants permet de synchroniser les priorités de tous. Ces discussions favorisent l'instauration d'une culture de hiérarchisation de groupe et garantissent que tous partagent le même état d'esprit à propos du programme

Le backlog produit sert également de base à la planification des itérations. Toutes les tâches doivent être incluses dans le backlog : user stories, bugs, changements apportés à la conception, dette technique, requêtes du client, actions issues de la rétrospective, etc. Cela permet de s'assurer que les tâches de tout le monde sont prises en compte lors de la discussion générale concernant chaque itération. Les membres de l'équipe peuvent alors faire des compromis avec le responsable produit avant de commencer une itération, en pleine connaissance de tout ce qui doit être fait.

Pro Tip:

Les responsables produit établissent la priorité des tâches dans le backlog, tandis que l'équipe de développement détermine la vélocité à chaque étape du backlog. Cette relation peut s'avérer délicate pour les nouveaux responsables produit qui cherchent à « imposer » du travail à l'équipe. Pour en savoir plus, lisez notre article consacré au flux et aux limites WIP.