3 exemples de backlogs produit réussis (+ ce qu’il ne faut pas faire)
Avez-vous déjà regardé votre backlog et eu envie de tout supprimer pour repartir de zéro ? Eh bien, j'ai ressenti cela plus d'une fois, car créer et maintenir des backlogs produit n'est pas une mince affaire. Mais, pour vous montrer comment bien gérer les backlogs et vous inspirer à faire le ménage dans le vôtre, laissez-moi vous présenter quatre exemples exceptionnels de backlogs produit.
Qu'est-ce que le backlog produit en Agile et Scrum ?
Le backlog produit est un document vivant qui rassemble tous les éléments sur lesquels l’équipe produit, le scrum master et l’équipe d’ingénierie prévoient de travailler pour développer leur produit.
Il comprend tout ce dont vous avez besoin pour développer et maintenir votre produit, y compris les nouvelles fonctionnalités, les tâches de dette technique, les améliorations de processus technique issues de votre dernière rétrospective, les tâches d’automatisation de la QA, et bien plus.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
La caractéristique fondamentale d'un backlog produit est qu'il s'agit d'une liste priorisée où les éléments en haut de la liste ont la plus haute priorité, et que l'équipe doit traiter en premier lorsqu'elle planifie ses sprints (ou lorsqu’elle dispose d’espace disponible sur son tableau kanban).
Backlog produit vs backlog de sprint vs feuille de route produit : quelle différence ?
En gestion de projet Agile, et plus particulièrement dans la méthodologie Scrum, le backlog produit n’est pas la seule liste d’éléments que le product owner crée pour votre équipe de développement. Il existe aussi le backlog de sprint et la feuille de route produit. Mais quelle est la différence entre eux ? Voyons cela ensemble.
Backlog de sprint : il s'agit d'un sous-ensemble du backlog principal et il contient uniquement les éléments que l'équipe Scrum a sélectionnés pour le prochain sprint ou une autre itération suite à la réunion de planification de sprint. Les éléments y sont généralement bien affinés et comprennent des points d'histoire.
Feuille de route produit : il s'agit d’un document de vue d’ensemble qui présente les principales fonctionnalités et grandes étapes du produit. Contrairement au backlog, qui est plutôt tactique et contient des descriptions détaillées des fonctionnalités, la feuille de route produit est stratégique et vise à montrer aux membres de l’équipe et aux parties prenantes la direction du produit ainsi que les axes de priorité.
Maintenant que vous connaissez ces concepts clés, laissez-moi entrer directement dans le vif du sujet pour vous expliquer comment gérer efficacement votre backlog produit (et aussi, comment ne surtout pas faire).
Comment ne surtout pas faire : voici un exemple de backlog produit désastreux
Comprendre les anti-patterns de création et de gestion d'un backlog produit est probablement aussi important que d’en apprendre les bonnes pratiques. Car si vous ignorez qu’une pratique est un anti-pattern, vous risquez de vous y retrouver dans votre propre backlog en pensant qu’il s’agit de quelque chose de normal ou d’acceptable.
Pour passer en revue quelques-unes des pratiques qui peuvent sérieusement nuire à la qualité de votre backlog, examinons l’exemple ci-dessous.
Revenons à l’exemple. Prenez le temps de bien l’examiner.
Ça a l’air affreux, n’est-ce pas ? En fait, en regardant ce backlog, la plupart d’entre nous ressentiront deux émotions :
- Du dégoût face au désordre des éléments présents dans ce backlog.
- De la culpabilité, car soyons honnêtes, nous avons tous déjà eu un backlog ressemblant à cela (moi y compris, bien sûr).
Passons maintenant en revue les problèmes de ce backlog.
Surcharge d’éléments dans le backlog produit
Avez-vous remarqué qu’il y avait 665 tickets dans ce backlog ? Eh bien, le plus gros backlog que j’ai eu la « joie » de gérer comptait plus de 2 500 éléments.
Le problème d’un backlog surchargé, c’est que vous serez presque à coup sûr incapable de vous rappeler ce que représente chaque ticket ni pourquoi il se trouve à telle ou telle position/priorité dans votre backlog. Et comme ces tâches vous semblent énigmatiques, il y a peu de chances que vous les abordiez lors de votre prochaine session d’affinage, que vous en discutiez les détails ou que vous les intégriez dans le prochain sprint.
Vous vous retrouvez donc avec un énorme désordre ingérable qui ne cesse de s'accumuler à l'infini.
Priorisation inappropriée du backlog
Un autre problème que vous avez peut-être remarqué dans cette liste de backlog est la présence d'éléments de travail avec des priorités « La plus basse » et « Basse » placés en haut — avant des éléments ayant une priorité « La plus haute ».
Cela représente le cas typique où le backlog n'est pas correctement priorisé. Il peut y avoir de nombreuses raisons à cela, mais la plus probable est que vous avez rétrogradé un élément à « Haute » priorité en le plaçant plus bas dans le backlog mais que vous avez oublié de modifier le champ de priorité.
Manque de détail
Avez-vous remarqué l'élément indiquant « Je veux une intégration transparente avec toutes les plateformes de réseaux sociaux » ? LOL. Ce n’est même pas une vraie user story, vu l’ampleur colossale du périmètre visé. L’étendue est tellement large que, dans la pratique, il vous faudrait plusieurs épiques pour la couvrir, chaque épique regroupant les stories correspondant à une plateforme sociale spécifique.
En plus de l’étendue massive, le problème de cet élément (en fait, de chaque élément de ce backlog) est son manque de clarté. Les user stories sont censées décrire une expérience utilisateur et une action précises.
Imaginez apporter cette story à la réunion de refinement avec votre équipe Agile. Vous feriez face à une avalanche de questions sur presque tous les aspects de la story.
« Que voulez-vous dire par transparente ? » « À quoi ressemble cette intégration ? » « Avec quelles plateformes sociales allons-nous nous intégrer ?! »
« Je veux tout, et tout de suite »
Un autre signal d’alerte que vous avez peut-être relevé dans le backlog est que 70 % des éléments ont une priorité « La plus haute ». Il s’agit là encore d’une situation typique lorsque vous vous fiez uniquement à l’avis de vos parties prenantes pour fixer les priorités (et chaque partie prenante considère ses éléments comme importants) sans chercher à les évaluer objectivement et à comparer leur importance à celle des autres éléments de la liste.
Maintenant que nous avons défini ce qu’est un mauvais backlog, corrigeons-le et voyons quatre exemples de bons backlogs… afin de vous aider à améliorer le vôtre.
3 exemples de backlogs bien gérés
Avant de vous montrer ces exemples, je tiens à préciser qu’il n’existe pas une seule façon correcte de concevoir un bon backlog. La structure de votre backlog dépendra de la nature de votre produit, de son niveau de maturité, de la taille de votre entreprise/équipe, etc.
En réalité, un backlog efficace est celui qui permet d’apporter clarté et alignement à tous concernant le périmètre actuel et futur de votre produit.
Cependant, il existe des approches universelles pour gérer votre backlog qui le rendront plus organisé et facile à utiliser par tous. Chacun des exemples ci-dessous illustre une telle bonne pratique.
Exemple n°1 : un backlog structuré en sections
Il n’est presque jamais acceptable d’avoir un backlog contenant des centaines, voire des milliers d’éléments. Toutefois, avoir environ 100 éléments est assez courant et normal. Mais même avec une centaine d’éléments, il est facile d’oublier à quoi correspond chacun, ou de les laisser de côté longtemps sans jamais les intégrer aux prochains sprints.
Pour rendre votre backlog plus organisé, vous pouvez envisager de le diviser en sections.
Certains Product Managers aiment utiliser des sections pour regrouper les éléments selon leurs domaines d’intérêt ou les jalons. Personnellement, je préfère utiliser les tags Version, Epic et Composant sur les tâches pour cela, et structurer mon backlog en sections basées sur le périmètre des prochains sprints.
C’est un excellent moyen d’assigner un sprint (ou au moins une période d’implémentation approximative) à la grande majorité des éléments de votre backlog et de vous assurer qu’aucune tâche n’est laissée à l’abandon.
Une autre façon courante de gérer le backlog à l'aide de sections consiste à regrouper les éléments en fonction de leur statut de raffinement ou de leur workflow (c’est d’ailleurs un aspect sur lequel l’IA dans la gestion du backlog peut vous aider). Dans ce cas, vous simplifiez votre processus avec les sections suivantes :
- Sprint en cours
- Prêt pour la planification
- Prêt pour la préparation
- Backlog
Dans ce cas de figure, vous travaillez à l’ajout des exigences produit et des descriptions pour les éléments présents dans le backlog. Une fois les exigences prêtes, vous les envoyez dans la section « Prêt pour la préparation » qui sert de périmètre pour la prochaine réunion de raffinement.
Après avoir affiné un élément, vous le déplacez dans la section « Prêt pour la planification », indiquant ainsi qu’il est prêt et que l’équipe peut l’inclure dans le prochain sprint.
Exemple n°2 : Un backlog avec des composants, épopées et versions bien placés
Séparer votre backlog en segments le rendra plus propre et plus organisé. Mais la limite d’une segmentation unique est que vous n’organisez votre backlog qu’en fonction d’un seul critère (par exemple, les sprints, le statut de préparation, etc.).
Heureusement, les outils modernes de backlog produit vous offrent davantage d’options pour organiser votre liste de tâches de développement selon plusieurs critères. Regardez ce backlog parfaitement organisé.
Ne trouvez-vous pas cela bien organisé et agréable à voir ? Dans ce cas précis, nous avons tiré parti des fonctionnalités suivantes pour rendre notre backlog plus facile à gérer :
Composants
Ce champ/caractéristique décrit traditionnellement la zone du produit dans laquelle vous souhaitez intégrer la fonctionnalité en question. Dans l’exemple ci-dessus, les composants représentent les produits distincts qui constituent Grammarly.
Une autre façon courante d’utiliser les composants consiste à organiser les stories ou tâches selon la technologie requise pour créer la fonctionnalité. Pour les applications web par exemple, vous pouvez avoir des composants Frontend/Backend pour vous aider à organiser le travail et les dépendances entre les ingénieurs spécialisés soit dans le développement côté client, soit côté serveur.
Versions / Versions de publication
Avec cette caractéristique, vous documentez toutes les fonctionnalités et corrections de bugs que votre équipe scrum publiera dans une certaine version de votre produit. Le suivi des versions dans le backlog présente deux avantages précieux.
- Il vous aide à planifier vos sprints et vos versions. Par exemple, si vous prévoyez une version dans 2 semaines, alors, lors de la réunion de planification, vous devez vous assurer d’inclure toutes les tâches prévues pour cette version dans le sprint.
- Vous pouvez documenter tout ce que votre équipe a intégré dans une version donnée et retracer facilement les problèmes lorsqu’un incident survient en production.
Par exemple, imaginez que les utilisateurs commencent à rencontrer des erreurs Captcha sur votre parcours d’inscription dans la dernière version 1.3.2. En cherchant la tâche basée sur laquelle votre équipe a modifié la configuration du captcha, vous voyez qu’elle appartient à la version 1.3.1. Cela signifie que vous devrez soit revenir à la version 1.3.0, soit effectuer un correctif d’urgence.
Épopées
Eh bien, je ne pense pas avoir besoin d’expliquer ce qu’est une épopée ni quels avantages elle apporte. Mais si vous souhaitez approfondir les bonnes pratiques et tous les détails concernant les épopées, vous pouvez consulter notre guide complet sur les épopées (jeu de mots voulu).
Exemple n°3 : Un backlog avec le bon niveau de détail pour chaque section
Il s’agit d’une bonne pratique que vous avez probablement croisée dans de nombreux livres et théories au sujet de l’agilité et la gestion de produit. Même si nous avons tendance à devenir plus sceptiques vis-à-vis des concepts théoriques avec l’expérience, celle-ci est réellement utile en pratique.
L’idée : les éléments placés en haut doivent comporter de nombreux détails et idéalement avoir déjà fait l’objet d’un raffinement du backlog produit au moins une fois. Les éléments du bas, quant à eux, ne devraient comporter que peu de détails, car il y a de fortes chances que vous appreniez de nouvelles choses sur votre produit et vos utilisateurs et que cet élément devienne obsolète.
Cela signifie que si l’élément en haut de votre backlog ressemble à ceci (ou est encore plus détaillé) :
Les récits en bas de votre backlog devraient comporter beaucoup moins de détails et ressembler à ceci :
Et tous les récits et initiatives situés au milieu de votre backlog auront un niveau de détail intermédiaire.
Exemple n°4 : Je sais que c’est évident, mais… un backlog propre
Je sais qu’il n’est pas facile de garder un backlog propre. J’ai moi-même vécu cette situation de nombreuses fois et je sais que cela ressemble à une corvée. Cependant, ne pas tout revoir dans votre backlog et oublier de vous débarrasser des éléments obsolètes sont des facteurs majeurs qui déterminent la qualité de votre backlog.
Il n’est pas toujours facile de supprimer des choses de votre backlog. Il y a vraiment des fonctionnalités intéressantes que vous espérez réaliser un jour (principalement des éléments « nice-to-have ») et parfois vous n’avez pas vraiment envie de vous en débarrasser. Mais à un certain moment, soyons honnêtes, vous savez que vous ne les réaliserez jamais. Et même si vous le faisiez, cela signifierait que vous n’avez plus de fonctionnalités hautement prioritaires, ce qui n’est généralement pas bon signe.
Parfois, ce sont vos parties prenantes qui ont créé ces éléments obsolètes dans votre backlog. Avant de les retirer, vous essayez de leur demander si leur demande est toujours d’actualité et leur réponse est presque toujours oui. Eh bien, si la demande date de plus de 6 mois et qu’ils l’avaient déjà oubliée, persuadez-les simplement que ce n’est pas urgent (si ça l’était, ils auraient relancé plusieurs fois) et supprimez-la.
Un backlog efficace est celui qui vous convient le mieux
Si vous preniez en compte toutes les bonnes pratiques ici, auriez-vous un backlog parfait ? Elles vous aideront, mais elles ne garantissent pas l’excellence.
N’oubliez pas que le but du backlog est d’être une source unique de vérité pour tout le monde. Ainsi, au-delà de ces bonnes pratiques, vous devez aussi tenir compte des besoins et du mode de fonctionnement de votre équipe et de vos parties prenantes, puis construire votre backlog de façon à les aider à rester alignés.
Ce guide sur la gestion d’un excellent backlog fait partie d’une série plus large sur l’Agile. Abonnez-vous à notre newsletter pour recevoir, toutes les deux semaines, d’autres guides et conseils comme celui-ci dans votre boîte mail !
