Outil de travail indispensable au Product Manager, le product backlog est une liste ordonnée et évolutive des tâches à effectuer par l’équipe. Il permet aussi de recueillir l’ensemble des caractéristiques du produit. Mais saviez-vous qu’il existe en fait deux types de product backlog ? Eh oui : en product management, il y a le backlog de Discovery et le backlog de Delivery (ce dernier désignant par défaut le product backlog agile). Explications.
Backlog de Discovery ou backlog de Delivery ?
Backlog peut être traduit en français par “accumulation de travail”. Pour bien faire du product management, il est important de distinguer deux types de product backlog : le backlog de Discovery et le backlog de Delivery (ou backlog agile). Ces deux backlogs peuvent tout à fait coexister au sein d’un même produit, mais il faut bien les dissocier.
Le backlog de Discovery
Même s’il est moins populaire que le backlog de Delivery (auquel renvoie traditionnellement le terme product backlog), le backlog de Discovery n’en demeure pas moins essentiel à la réussite d’un produit. Il désigne la liste des problèmes à résoudre et des opportunités d’amélioration du produit (essentiellement du point de vue des clients).
Ce type de backlog peut être priorisé avec des critères spécifiques à chaque produit : volume de feedbacks utilisateurs, impact sur le business, effort de développement, etc. Il doit être bien organisé en grandes thématiques, puis en problèmes et en sous-problèmes afin d’y voir plus clair. En revanche, il faut éviter d'avoir une liste de courses infinie d’éléments à traiter dont on ne sait pas quoi faire. Le risque étant de produire un outil peu pertinent, voire inutilisable.
C'est pourquoi il faut passer du temps à parler avec ses clients, de façon à bien comprendre leurs besoins et à pouvoir les formaliser de façon précise, sous la forme de user stories par exemple.
En plus d’être clair et efficace, le backlog de Discovery doit être priorisé en cohérence avec les objectifs stratégiques de l'entreprise. Ce backlog est sous la responsabilité directe du Product Manager.
Le backlog de Delivery
Le backlog de Delivery est la continuité directe du backlog précédent. Une fois que le backlog de Discovery est terminé (avec chaque problème priorisé), l'équipe produit, en collaboration avec le design et les équipes techniques, vont définir les solutions à implémenter. Ces solutions se peuvent se découper en EPIC et en tâches, qui constituent le backlog de Delivery (aussi appelé backlog agile).
Avec le product backlog de Delivery, l’enjeu est de prioriser les tâches par rapport à une logique d'implémentation technique (par exemple : il faut que le backend soit prêt avant de démarrer le frontend), mais aussi par rapport aux ressources techniques disponibles (par exemple : qu'est-ce que l’équipe produit peut faire dans le temps imparti pour un cycle de développement ?).
Ce product backlog est souvent sous la responsabilité du Product Owner, bien qu’il soit aussi accessible au reste de l’équipe produit. Ce document est le point central de tout projet développé en méthode SCRUM. Car c’est à partir du backlog agile que les sprints seront planifiés. Il servira alors de base à la réunion de sprint planning (qui marque le lancement d’un sprint).
Une fois qu'un sprint a démarré, la priorisation ne devrait plus changer, au risque de faire perdre l'équipe technique en efficacité et de créer de la frustration. Par contre, à l'échelle d'un projet plus grand impliquant plusieurs sprints, le backlog peut tout à faire être repriorisé en fonction de l'avancement pour prendre en compte un nouveau contexte.
Product backlog : pourquoi séparer les deux types de backlog ?
En suivant les principes agiles, l’équipe produit a tout intérêt à séparer les deux versions de product backlog. Voici les avantages à procéder de la sorte :
- Permet de s'assurer que l’équipe travaille d'abord et avant tout sur les bons problèmes à un instant T et qu'elle prend du recul sur la priorisation ;
- Permet de prioriser les problèmes entre eux et fonctionnalités entre elles, et donc de comparer ce qui est comparable ;
- Permet de ne pas accumuler des listes infinies d'éléments à prioriser qui ne forment plus un tout logique ;
- Permet de faire le lien entre les tâches des équipes de développement, les objectifs business, et les besoins des clients.
Comment prioriser son product backlog ?
Avant de démarrer un travail de priorisation, il faut d'abord une définition des objectifs stratégiques qui vont guider la prise de décision. De bons objectifs produit découlent directement des objectifs stratégiques de l'entreprise et visent donc à avoir un impact business. Ils peuvent être de nature qualitative et quantitative, avec un objectif de résultat chiffré. Voici quelques exemples d'objectifs :
- diminuer le taux de churn de 20% ;
- augmenter la base utilisateurs de 30% ;
- atteindre 1 million d'euros de CA pour mon nouveau produit d'ici 1 an.
Après la définition des objectifs, on peut alors définir les critères de priorisation pour son product backlog. Ces critères dépendent bien sûr des objectifs et ils sont susceptibles de varier dans le temps. En général, ces critères vont mesurer d'un côté l'impact potentiel d'un item du backlog, et de l'autre son coût estimé. On aura alors tendance à sélectionner les items qui maximisent l'impact avec un coût le plus faible possible, donnant ainsi le meilleur retour sur investissement. Voici des exemples de critères de priorisation :
- impact sur le revenu ;
- impact sur churn ;
- ressources nécessaires pour développer une fonctionnalité.
Une bonne définition des critères de priorisation permet à la fois de prendre les bonnes décisions, mais facilite aussi la justification des choix faits par l'équipe produit auprès des autres parties prenantes : management, équipes métiers, voire même auprès des clients dans un contexte B2B.
Enfin, il faut mettre en place un système de statuts pour représenter la priorité d'un item dans le backglog. Ces statuts permettront de communiquer ce sur quoi l'équipe travaille aujourd'hui, demain et ce qui a déjà été réalisé. A la place ou en compléments des statuts, on peut aussi prioriser son product backlog sur une échelle de temps, voire se fixer des objectifs de dates précises.
On peut alors commencer à prioriser les items de son backlog, en utilisant les étapes suivantes :
- Passer en revue les items du product backlog et exclure tous ceux qui ne sont pas cohérents avec les objectifs fixés ;
- Pour les items restants, veiller à ce qu'il n'y ait pas de duplicatas et effectuer des groupements quand cela fait sens ;
- Évaluer chaque item selon les critères de priorisation définis ;
- Construire un score qui prend en compte tous les critères (moyenne pondérée, score RICE, etc.) ;
- Classer les items par ordre décroissant en fonction de ce score ;
- Passer en revue le classement et prendre les décisions finales de priorisation en attribuant un statut aux différents items priorisés.
Ces étapes peuvent être utilisées pour prioriser un backlog de Discovery et un backlog de Delivery. L'important est que chaque équipe doit adapter sa méthode de priorisation à son contexte particulier.
Bien que le product backlog en méthode agile ait tendance à désigner uniquement le backlog de Delivery, il serait dommage de vous priver du travail amont permis par le backlog de Discovery. Les deux sont indissociables pour optimiser votre product management. Si vous souhaitez aller plus loin, l’outil d’Harvestr vous aidera à structurer votre priorisation et à maximiser l'impact de vos décisions. Découvrez notre plateforme tout-en-un.