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

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).

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. 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.

Essayer les tableaux Scrum Jira

A well-managed product backlog can bring numerous benefits to a development team. Some of the key benefits include:

• Improved prioritization: A product backlog helps to ensure that the most critical tasks are being worked on first.

• Increased efficiency: By prioritizing tasks based on customer feedback and business objectives, teams can ensure they work on the most valuable tasks.

• Better communication: A product backlog ensures everyone is aligned and working towards the same goals.

• Reduced waste: By prioritizing tasks based on customer feedback and business objectives, teams can reduce waste and ensure that they are not working on tasks that are not valuable.

• Improved customer satisfaction: By prioritizing tasks based on customer feedback, teams can ensure they deliver customers' desired features and functionality.

Overall, a well-managed product backlog is essential for agile product development. It ensures that teams are working on the most valuable tasks and that everyone is aligned and working towards the same goals.

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)

Une 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 prioriser le backlog, cette tâche est rarement faite dans le vide. Les meilleurs Product Owners 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.

Élaborer une feuille de route produit

Une feuille de route produit est un plan de haut niveau qui décrit la vision, les buts et les objectifs du produit. Elle 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.

Répertorier les tâches du 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.

Communiquer avec l'équipe

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.

Étape 1. Évaluer les besoins des clients

• 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.

Étape 2. Évaluer l'urgence du feedback

• 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.

Étape 3. Tenir compte de la complexité de la mise en œuvre

• É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.

Étape 4. Tenir compte des dépendances

• 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 établi, il est crucial de le maintenir à jour afin de 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. Certaines équipes utilisent le terme « peaufinage du backlog ».

Au fur et à mesure que le backlog s’étoffe, les Product Owners doivent le classer en éléments à court terme et à long terme. Les éléments à court terme doivent être complètement définis avant d’être libellés comme tels.

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é finalisée, et que les estimations de l’équipe de développement ont été obtenues.

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 qu'elle aura 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.

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.