Backlog produit : conseils pour créer et hiérarchiser

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.

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 de produit en fonction de ses capacités, soit en continu (Kanban), soit par itération (Scrum).

Dans le framework Scrum, le backlog produit Scrum est une liste structurée et soigneusement tenue à jour utilisée par le Product Owner Scrum pour orienter les tâches de l'équipe de développement.

Essayer les tableaux Scrum Jira

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.

Un backlog produit bien géré peut apporter de nombreux avantages à une équipe de développement. Parmi les principaux avantages, citons :

• Meilleure hiérarchisation des priorités : un backlog produit permet de s'assurer que les tâches les plus critiques sont traitées en premier.
• Efficacité accrue : en hiérarchisant les tâches en fonction du feedback des clients et des objectifs métier, les équipes peuvent s'assurer qu'elles travaillent sur les tâches les plus importantes.
• Meilleure communication : un backlog produit permet à tout le monde d'être sur la même longueur d'onde et d'atteindre les mêmes objectifs.
• Réduction du gaspillage : en hiérarchisant les tâches en fonction du feedback des clients et des objectifs métier, les équipes peuvent réduire le gaspillage et s'assurer qu'elles ne travaillent pas sur des tâches sans intérêt.
• Amélioration de la satisfaction client : en hiérarchisant les tâches en fonction du feedback des clients, les équipes peuvent s'assurer qu'elles proposent les caractéristiques et fonctionnalités souhaitées par les clients.

Dans l'ensemble, un backlog produit bien géré est essentiel pour développer des produits de manière agile. Cela garantit que les équipes travaillent sur les tâches les plus importantes et que tout le monde est aligné et travaille pour atteindre les mêmes objectifs.

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)

La hiérarchisation efficace du backlog produit garantit que les tâches les plus critiques sont abordées en premier, en équilibrant l'autonomie de l'équipe avec les exigences du Product Owner.

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.

La création d'un backlog produit est une étape cruciale pour développer des produits de manière agile. Cela implique d'établir une feuille de route produit, de répertorier les tâches du backlog produit et de communiquer avec l'équipe.

Une feuille de route produit est un plan de haut niveau qui décrit la vision, les buts et les objectifs du produit. Il sert de base au backlog produit et permet de s'assurer que tout le monde est sur la même longueur d'onde et travaille vers les mêmes objectifs.

Pour établir une feuille de route produit, définissez la vision et la mission du produit. Ensuite, identifiez les principaux objectifs et buts à atteindre. Enfin, divisez les objectifs en tâches plus petites et gérables qui peuvent être ajoutées au backlog produit.

Une fois la feuille de route produit en place, il est temps de commencer à répertorier les tâches du backlog produit. Ces tâches peuvent inclure des fonctionnalités, des user stories, des bugs, des changements de design et de la dette technique.

Lorsque vous dressez la liste des tâches du backlog produit, incluez une description claire de chaque tâche et tous les détails pertinents, tels que la durée estimée et les ressources nécessaires. Il est également essentiel de hiérarchiser les tâches en fonction du feedback, des demandes et des objectifs métier des clients. Cela permet à l'équipe de développement de travailler sur les tâches les plus rentables.

Une communication efficace est essentielle pour créer un backlog produit. Le Product Owner doit travailler en étroite collaboration avec l'équipe de développement pour s'assurer que tout le monde comprend le backlog produit et les priorités. Le Product Owner doit également communiquer avec les autres équipes, telles que les équipes commerciales et marketing, afin de s'assurer que tout le monde est aligné et travaille pour atteindre les mêmes objectifs.

Des réunions et des mises à jour régulières permettent de s'assurer que tout le monde est sur la même longueur d'onde et que le backlog produit est géré de manière efficace.

Vous avez encore besoin de conseils ? Essayez le modèle de backlog produit gratuit de Jira.

La hiérarchisation du backlog est essentielle pour permettre à l'équipe de développement de se concentrer sur les tâches qui ont le maximum d'impact. Voici comment procéder :

Diverses techniques de hiérarchisation du backlog produit, telles que MoSCoW et la notation pondérée, peuvent aider les équipes à gérer et à ordonner les tâches de manière efficace. Le processus de hiérarchisation implique une révision et un réalignement réguliers des objectifs afin de s'adapter à un environnement métier dynamique.

• Identifiez les fonctionnalités ou les corrections qui auront le plus de valeur pour vos utilisateurs.
• Utilisez le feedback des clients, les enquêtes ou les analyses pour identifier les priorités.

• Priorisez les tâches qui généreront des informations exploitables pour l'équipe ou les parties prenantes.
• Par exemple, le fait de tester une nouvelle fonctionnalité plus tôt peut permettre d'économiser du temps et des ressources par la suite.

• Équilibrez votre backlog en incluant des projets à succès rapide et des projets plus complexes et à long terme.
• Évaluez le ratio effort/impact pour vous assurer que les ressources sont dépensées à bon escient.

• Identifiez les tâches qui doivent être achevées avant que d'autres ne puissent commencer.
• Rationalisez les workflows en vous occupant d'abord des tâches de base.

Des outils fiables qui permettent de hiérarchiser les backlogs peuvent rationaliser le développement des produits et améliorer l'efficacité. Alors que le Product Owner dirige la définition des priorités, l'implication de l'équipe de développement, des concepteurs et des parties prenantes favorise une compréhension commune des priorités. Des discussions régulières garantissent l'alignement et améliorent la prise de décisions.

Conseil de pro : utilisez des frameworks de priorisation tels que MoSCoW (« indispensable », « souhaitable », « possible » et « à éviter ») ou une notation pondérée pour prendre des décisions objectives fondées sur des données. Les équipes peuvent mettre en œuvre leurs propres frameworks de priorisation grâce à la fonctionnalité de priorisation flexible de Jira Product Discovery.

Une fois le backlog produit constitué, il est crucial de le maintenir à jour pour suivre régulièrement le rythme du 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, souvent appelé peaufinage du backlog produit dans les cercles Agile, permet de s'assurer que les tâches sont alignées sur les idées des parties prenantes et de préparer l'équipe pour le sprint à venir (certains utilisent le terme de peaufinage du backlog).

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 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 consistent 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 peut revoir à tout moment les tâches prioritaires du backlog en fonction du feedback des clients, de la révision des estimations et des nouvelles exigences. Cependant, une fois le travail en cours, les changements doivent être limités, car ils perturbent l'équipe de développement et affectent la concentration, la fluidité et le moral.

Astuce : lorsque le backlog dépasse les capacités à long terme de l'équipe, il est normal de clôturer les tickets que l'équipe n'aura jamais à traiter. Pour les recherches futures, signalez ces tickets avec une résolution spécifique, par exemple « hors périmètre », dans le système de suivi des tickets de l'équipe.

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.

Les Product Owners avisés préparent rigoureusement le backlog produit de leur programme afin de créer un aperçu fiable et partageable des tâches à accomplir dans le cadre du projet.

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.

Un backlog Agile bien hiérarchisé clarifie ce à quoi l'équipe a l'intention de consacrer du temps, en mettant en évidence les tâches visibles et internes. 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 Product Owner avant de commencer une itération, tout en ayant une parfaite connaissance de tout ce qui doit être fait.

Astuce : les Product Owners déterminent la priorité des tâches dans le backlog, tandis que l'équipe de développement détermine sa vélocité. Cette relation peut s'avérer délicate pour les nouveaux Product Owners qui cherchent à « imposer » du travail à l'équipe. Cet article explique les limites et le flux des travaux en cours.