Backlog de produit :
votre liste de tâches ultime

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
Browse topics

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 Product Owner, 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).  

Conseil de pro :

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ées ici en vert, bleu et bleu sarcelle) et user stories pour chacune de ces epics. 

Initiatives et epics Agile | Atlassian – Le coach Agile

Le Product Owner organise ensuite chacune des user stories en une liste unique pour l'équipe de développement. Il peut décider de fournir d'abord une epic complète (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 Product Owner 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 Product Owner soit chargé de hiérarchiser le backlog, cela ne se fait pas dans l'absolu. Les Product Owners 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 produit créé, il est important de l'actualiser régulièrement afin de l'adapter au programme. Les Product Owners 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 Product Owners 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 Product Owner et l'équipe de développement. Le Product Owner 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. 

Conseil de pro :

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 des tickets, afin de faciliter les recherches ultérieures. 

Anti-schémas à surveiller

  • Le Product Owner 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 Product Owners avisés préparent 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, demandes 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 Product Owner avant de commencer une itération, en pleine connaissance de tout ce qui doit être fait.

Conseil de pro :

Les Product Owners é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 Product Owners qui cherchent à « imposer » du travail à l'équipe. Pour en savoir plus, lisez notre article consacré au flux et aux limites WIP.