Présentation du backlog produit

Une fois que les résultats sont clairement définis, l'équipe peut se réunir et se pencher sur les idées de produits qui contribueront à les atteindre. La première mesure pragmatique que vous pouvez prendre pour y parvenir est d'adopter un backlog produit.

Dans le cadre de notre travail, nous avons rencontré de nombreuses équipes produit qui utilisaient un seul backlog Jira pour tout enregistrer : les demandes de fonctionnalités, les petites et les grandes opportunités, les tâches et les sous-tâches, les bugs et les tickets urgents, ainsi que les idées sur l'évolution du produit.

Invariablement, ils nous ont raconté la même histoire. Le backlog devient incontrôlable, avec une liste de tickets qui ne cesse de s'allonger, et devient une source d'anxiété. Ces backlogs désorganisés et accablants ne favorisent en aucun cas la hiérarchisation des priorités à tous les niveaux, qu'il s'agisse de changements tactiques ou de nouveaux investissements importants.

Les équipes ont fini par déplacer ces discussions dans des feuilles de calcul, mais c'était un jour sans fin chaque trimestre. Les informations se perdaient, les décisions n'étaient pas enregistrées et les ressources étaient allouées sous la pression du temps, sur la base d'un sentiment instinctif ou d'opinions bruyantes.

Il existe une meilleure solution : un backlog produit spécifique, axé sur les résultats, distinct du backlog de livraison pour le travail quotidien.

Qu'est-ce qu'un backlog produit ?

Le backlog produit est l'endroit où les idées sont créées, hiérarchisées et partagées sous forme de feuilles de route, en lien avec les résultats et les objectifs. Il contient toutes les idées de produits, les informations, les opportunités et les solutions, et appartient à l'équipe produit. Plutôt que de planifier des tâches spécifiques à exécuter, c'est un endroit pour discuter de « dans quoi devons-nous investir et pourquoi ? ». Les parties prenantes de l'entreprise peuvent être invitées à participer à ce backlog, pour collaborer sur les priorités et les feuilles de route, et pour discuter de l'avancement des initiatives relatives aux produits en cours de réalisation.

Considérez le backlog produit comme à une base pour l'équipe du produit, à partager avec les collaborateurs de toute l'entreprise. C'est un espace réservé à tout ce qu'ils veulent suivre, qu'il s'agisse d'idées vagues ou d'opportunités complètes, et à les affiner au fil du temps en fonction des enseignements tirés, du feedback des clients et de l'évolution des objectifs généraux.

Backlog produit et backlog de livraison

Le backlog produit est séparé du backlog de livraison, chacun ayant un objectif précis. 

Le backlog de livraison sert à gérer le travail de livraison, à créer des plans de livraison et à suivre les avancements. Il contient la répartition du travail (epics, stories, tâches et sous-tâches) sur la manière de tenir les engagements, et appartient à l'équipe d'ingénierie. C'est là que toute l'équipe se réunit et collabore pour discuter des problèmes de livraison : séquençage, dépendances, capacité, étapes techniques importantes.

De toute évidence, les backlogs produit et de livraison sont étroitement liés. Le travail effectué dans le backlog de livraison permet d'accéder aux idées du backlog produit, qui sont elles-mêmes liées aux résultats souhaités. Cela donne aux dirigeants, aux managers et aux développeurs une vue d'ensemble de la manière dont l'équipe travaille pour obtenir des résultats au fur et à mesure des cycles de découverte et de livraison.

Contrairement au backlog produit, tous les éléments du backlog de livraison sont conçus comme des plans concrets, qui seront achevés ultérieurement. En revanche, le backlog produit est destiné à l'idéation, au brainstorming et à la planification. Certaines idées de produits ne seront jamais hiérarchisées par ordre de priorité et ne figureront jamais sur les feuilles de route, et ce n'est pas grave.  

En séparant les préoccupations générales relatives aux produits de la planification et du suivi des livraisons, les équipes peuvent hiérarchiser des priorités plus efficacement, relier le travail aux résultats et éviter les backlogs incontrôlables qui essaient de satisfaire tout le monde.

Les avantages d'un backlog produit

L'utilisation de backlogs distincts pour le produit et la livraison présente de nombreux avantages :

• C'est un espace sûr où l'équipe produit peut discuter d'idées potentielles, en plus des données disponibles, sans se soucier de leur faisabilité ou de leur définition. 

• Il regroupe les discussions sur les produits en un seul endroit, afin que les équipes puissent acquérir des connaissances au fil du temps sans avoir à chercher dans des dizaines de feuilles de calcul.

• Cela crée une source de référence partagée et une compréhension commune des priorités des produits. Cela permet de résoudre un problème courant auquel sont confrontées les équipes produit : la prise de décisions sur la base de l'intuition ou de l'avis le plus fort des clients et des parties prenantes. 

• Cela crée de la transparence dans les discussions sur la hiérarchisation des priorités, en réunissant tous les acteurs de l'entreprise dans un espace partagé. Cela élimine de nombreuses difficultés lors de la collaboration avec les parties prenantes et les équipes en contact avec la clientèle.

• Il est lié au travail de livraison, de sorte que les feuilles de route ne deviennent pas obsolètes et restent honnêtes, car elles prennent en compte les contraintes de livraison.

Comment organiser le backlog produit

Les idées, les opportunités, les problèmes, les solutions : l'équipe produit doit décider ce qu'elle souhaite mettre dans le backlog produit. C'est ce que l'équipe essaie de hiérarchiser en fonction de la priorité et qui représente la façon dont l'équipe pense les investissements et les priorités en matière de produits.

Il est très important que l'équipe produit contrôle le contenu du backlog produit et la structure utilisée pour classer et hiérarchiser les idées. Dans le cas contraire, elle risque de voir son backlog dériver vers la désorganisation, ce qu'elle essayait d'éviter au départ.

Pour contrôler le backlog, les parties prenantes externes devraient être invitées à contribuer par des moyens prédéfinis, plutôt que par des privilèges directs de création et d'édition d'éléments. Par exemple, ces collaborateurs peuvent ajouter des commentaires, voter pour des idées ou mentionner le client qui a demandé une fonctionnalité.

Vous trouverez ci-dessous deux frameworks recommandés pour structurer un backlog produit : des rochers, des pierres et des cailloux, et des listes longues, moyennes et restreintes. Nous recommandons d'organiser le backlog produit en fonction de ces trois catégories et de ces activités.

Dans Jira Product Discovery, cela se fait en configurant des vues spécifiques pour présenter les bonnes idées, et en choisissant les champs à afficher pour faciliter la discussion (sélection, évaluation) et encourager la collaboration (informations, votes, commentaires, réactions).

Rochers, pierres et cailloux

De nombreuses équipes produit n'ont qu'un seul type d'objet : « idée ». Mais le backlog peut contenir des éléments de formes, de tailles et de niveaux de granularité différents, qu'il s'agisse de nouveaux paris importants ou de petites améliorations de produits. 

Une pratique courante consiste à structurer un backlog en trois catégories d'éléments : 

• Rochers : investissements importants, opportunités stratégiques et nouveaux paris importants

• Pierres : investissements moyens, améliorations substantielles des produits qui permettent d'obtenir des résultats

• Cailloux : petits investissements, comme la correction de bugs de type « coupures de papier » et de problèmes d'expérience utilisateur

Il est préférable de créer des zones distinctes pour ces produits dans le backlog produit, et de penser à équilibrer les investissements entre les trois, en réservant un budget et un espace sur la feuille de route pour chacun d'entre eux. Les cailloux, en particulier, sont difficiles à classer par ordre de priorité sans ce type d'intentionnalité. Un nouveau pari important est excitant, mais les coupures de papier ont un effet négatif sur l'expérience utilisateur. 

Pour en savoir plus sur ce framework, consultez la section Idées.

Liste longue, moyenne et courte

Une autre façon simple et pragmatique de structurer le backlog produit nous vient de Brent Johnston, l'un des premiers utilisateurs de Jira Product Discovery. Brent Johnston a décrit le travail sur les produits comme étant un travail constant avec trois catégories : la liste longue, la liste moyenne et la liste courte.

L'équipe produit prend les idées de la liste longue, moyenne et courte pour les présélectionner dans le backlog produit, en invitant les parties prenantes de l'ensemble de l'entreprise à collaborer.

• La liste longue contient tout : « un jour, peut-être des idées », des problèmes, des opportunités ou des solutions. Il peut y avoir plus de 200 idées sur cette liste. 

  • L'équipe produit dresse cette liste longue en utilisant sa connaissance du marché, des préoccupations stratégiques et opérationnelles, ainsi que des besoins des clients et des entreprises, pour en faire une liste moyenne.

• La liste moyenne est une présélection des priorités potentielles : des opportunités attrayantes dans lesquelles l'équipe pourrait investir légitimement. Sur une liste longue de 200 idées, 10 à 20 peuvent figurer sur la liste moyenne.

  • Ce sont des idées qui semblent bonnes parce qu'elles sont importantes sur le plan stratégique, qu'elles sont fréquemment abordées lors des discussions avec les clients ou parce qu'elles ont le potentiel de ravir les utilisateurs. Elles doivent être classées par ordre de priorité sur une liste courte, généralement avec la contribution des différentes parties prenantes de l'entreprise. 

    • Pour plus d'informations, voir Hiérarchisation.

• La liste courte est essentiellement la feuille de route du produit : les idées que l'équipe produit s'est engagée à explorer davantage. Ces tâches permettent de mettre en œuvre des opportunités, des problèmes ou des solutions, afin de commencer à créer une expérience produit ou d'améliorer une expérience existante. 

  • L'équipe revoit régulièrement cette liste en fonction de ce qu'elle apprend et la tient à jour. C'est la liste sur laquelle le reste de l'entreprise peut s'attendre à recevoir une mise à jour le plus régulièrement possible.

    • Pour plus d'informations, voir Feuille de route.

Comment créer un backlog produit dans Jira Product Discovery

Nous avons créé Jira Product Discovery pour permettre aux équipes produit de recueillir leurs idées, de collaborer sur celles-ci et de les hiérarchiser. Dans Jira Product Discovery, vous pouvez créer un ou plusieurs backlogs produit, appelés « Projets de découverte ». 

En général, il est préférable de réunir des personnes qui travaillent ensemble au quotidien sur le même projet (par exemple, une ou plusieurs équipes). Cependant, de nombreux clients de Jira Product Discovery utilisent un seul projet pour héberger plusieurs équipes et produits. C'est particulièrement utile lorsqu'un haut niveau de collaboration est requis entre ces équipes.

Cette démo vous explique comment procéder :

Avec l'offre Jira Product Discovery Premium, vous êtes en mesure de visualiser les idées de plusieurs projets en un seul endroit, en créant des vues qui montrent les idées de plusieurs projets et racontent toute l'histoire des plans de produits d'une organisation.

Et ensuite ?

Dans le reste de ce manuel, nous expliquerons en détail comment utiliser un backlog produit pour :

• faire passer les idées de leur conception à leur mise en œuvre ;

• mettre en place des canaux de feedback et collecter des insights pour valider des idées ;

• prioriser les idées susceptibles d'avoir un impact ;

• créer des feuilles de route auxquelles vos équipes et les parties prenantes pourront adhérer.

Nous vous fournirons des exemples sur la façon dont nous procédons au sein de l'équipe Jira Product Discovery, en utilisant Jira Product Discovery ainsi que d'autres produits.