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 hiérarchisée de tâches destinées à l'équipe de développement. Il est créé à partir de la feuille de route produit 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).
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.
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.
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.
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 Product Owner soit chargé de hiérarchiser le backlog, cette tâche est rarement faite dans le vide. Les responsables produit efficaces cherchent à recueillir les commentaires et le feedback des clients, des designers et de l'équipe de développement afin d'optimiser l'ensemble des charges de travail et la livraison des produits.
Comment gérer efficacement un backlog produit
Une fois que le backlog a été créé, il est important de l'actualiser régulièrement afin de l'adapter au programme. Les Product Owners doivent réviser 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é. L'examen régulier du backlog est souvent appelé « préparation du backlog » dans les cercles Agile (certains utilisent le terme « affinement du backlog »).
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 Product Owner et l'équipe de développement. Le Product Owner est libre de revoir à tout moment les tâches prioritaires du backlog suite au feedback des clients, à la révision des estimations et aux nouvelles exigences. Une fois que la tâche est en cours, limitez les changements, car ils perturbent l'équipe de développement et jouent sur la concentration, le flux et le moral.
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 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.
Les backlogs produit permettent aux équipes de rester agiles
Les responsables produit 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 comprises dans le backlog : user stories, bugs, modifications au niveau de la conception, dette technique, demandes du client, éléments d'action issus de la rétrospective, etc. Cela permet de s'assurer que les tâches de tous sont prises en compte lors de la discussion générale autour de chaque itération. Les membres de l'équipe peuvent alors faire des compromis avec le responsable produit avant de commencer une itération, tout en ayant une parfaite connaissance de tout ce qui doit être fait.
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.
Prêt à vous lancer ? Découvrez comment créer votre backlog dans Jira.
Priorisez ce qui compte grâce au modèle Jira Scrum
Bénéficiez d'une visibilité totale sur le travail à accomplir pour vous concentrer sur les tâches ayant le plus d'impact.
Ressources associées
