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, impacts 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. Le risque étant de produire un outil peu pertinent, voire inutilisable. Il faut éviter d'avoir une liste de courses infinie d’éléments à traiter dont on ne sait pas quoi faire.
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 Discovery est la continuité directe du backlog précédent. Une fois que le backlog de Discovery est terminé (avec chaque problème priorisé), les équipes techniques vont définir les solutions à implémenter. Ces solutions se découpent 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 châssis soit prêt avant d'installer la carrosserie), 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 sous la responsabilité du Product Owner, bien qu’il soit aussi accessible à 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).
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 ne pas accumuler des listes infinies de choses à faire, qui ne forment plus un tout logique ;
- Permet de faire le lien entre les tâches des équipes de développement et le contexte business derrière.
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 va vous intéresser. Cliquez ici pour le découvrir.