Certains propriétaires de produits (Product Owners) pensent qu’un arriéré de produit (Product Backlog) complet est le meilleur moyen d’atteindre l’objectif du produit et d’être en même temps totalement transparent .

The Expensive Folly of the Oversized Product Backlog par Stefan Wolpers

https://age-of-product.com/oversized-product-backlog/

Les coûts d’un arriéré de produit surdimensionné

Apprenez-en davantage sur l’impact négatif d’un Product Backlog surdimensionné sur l’innovation, la capacité de votre équipe Scrum à créer de la valeur et vos relations avec les parties prenantes.

Les effets secondaires coûteux d’un arriéré de produit surdimensionné

Certains Product Owners estiment en effet que tenir un Product Backlog surdimensionné est une stratégie optimale pour atteindre l’objectif du produit et maintenir une transparence totale, garantissant qu’aucune idée de valeur potentielle ne soit perdue. Cependant, construire à l’avance une liste complète de tous les éléments de travail imaginables n’est pas seulement une perte de temps pour une équipe Scrum, un Product Backlog surdimensionné est une erreur coûteuse à long terme.

Voici 8 effets secondaires critiques de cet anti-pattern (contre-modèle ou fausse bonne idée) du Product Backlog.

#1 – Encourage le gaspillage

Un Product Backlog surdimensionné favorise le gaspillage en investissant du temps dans des éléments qui ne seront peut-être jamais développés en raison de la découverte continue de tâches plus précieuses. C’est une violation claire des principes du Manifeste Agile. En particulier, la simplicité – l’art de maximiser le travail non fait – qui est essentielle.

#2 – Augmente les risques du piège des coûts irrécupérables

Un important Product Backlog peut favoriser le syndrome des coûts irrécupérables. Les équipes peuvent continuer à affiner et à prioriser des éléments parce qu’elles y ont déjà investi du temps plutôt que parce qu’ils ajoutent une valeur significative. Ce comportement contredit le principe d’amélioration continue et d’adaptation du Manifeste Agile.

#3 – Conduit à la paralysie d’analyse

Un énorme Product Backlog peut provoquer ce que l’on appelle la paralysie d’analyse, où le volume d’items devient écrasant, conduisant à l’indécision et aux retards. L’équipe peut passer trop de temps à évaluer, hiérarchiser et redéfinir les priorités, ce qui nuit à sa capacité à se concentrer sur le développement réel du produit. Cet excès de choix ralentit souvent les processus de prise de décision, ce qui rend difficile pour l’équipe de déterminer par où commencer ou sur quoi se concentrer ensuite. En fin de compte, cela ralentit l’ensemble du projet, détournant l’énergie de la création de valeur pour le client vers la gestion du Product Backlog lui-même.

#4 – Nuit à l’engagement des parties prenantes

Un Product Backlog gonflé présente un défi important en matière de communication efficace. Le grand nombre d’items peut rendre difficile pour les intervenants de comprendre le plan, les progrès et les priorités, ce qui peut entraîner un décalage dans les attentes. Les intervenants peuvent avoir du mal à trouver leurs intérêts spécifiques dans la longue liste, ce qui les rend confus et peut causer un sentiment de détachement.

#5 – Produit un effet d’éviction

Un Product Backlog complet et surdimensionné peut décourager sans le vouloir les parties prenantes et les membres de l’équipe de faire part de leurs réflexions et de leurs idées. L’exhaustivité perçue du Product Backlog pourrait donner l’impression qu’il n’y a pas de place ni de besoins supplémentaires à ajouter, ce qui pourrait faire perdre des idées précieuses.

#6 – Inhibe l’innovation

Un énorme Product Backlog peut involontairement étouffer l’énergie créative au sein de l’équipe Scrum. La longue liste de tâches peut créer une culture de « cocher les cases » où l’équipe se concentre davantage sur compléter des tâches plutôt que sur explorer et innover. L’équipe peut se sentir contrainte, percevant qu’il n’y a pas de place pour de nouvelles idées, ce qui peut limiter leurs compétences créatives en résolution de problèmes et les dissuader de trouver des solutions innovantes. Cet état d’esprit contredit la valeur Scrum de « l’ouverture » et le principe Agile d’exploiter le changement pour le bénéfice business du client.

#7 – Donne un faux sentiment de sécurité

Un Product Backlog exhaustif peut donner un faux sentiment de sécurité, une illusion de contrôle. Il peut sembler que l’équipe Scrum a identifié tout le travail nécessaire, réduisant ainsi le besoin perçu de découverte et d’apprentissage. Ce décalage avec le Guide Scrum, qui préconise l’apprentissage itératif et la découverte, peut être nuisible.

#8 – Encourage l’optimisation précoce

Un Product Backlog enflé peut conduire à une optimisation prématurée. L’équipe peut se sentir forcée de concevoir des systèmes ou des flux de travail qui anticipent l’achèvement des futurs éléments du backlog, ce qui entraîne une complexité inutile, contribuant au gaspillage si ces tâches changent ou sont dépriorisées par la suite. Cette approche entre en conflit avec le principe agile de simplicité (l’art de maximiser la quantité de travail non effectué) et la valeur Scrum de focus, car elle encourage l’effort dirigé vers des besoins futurs incertains plutôt que vers les besoins présents les plus précieux.

Comment contrer au mieux les effets d’un Product Backlog surdimensionné

Heureusement, il existe de nombreuses façons d’éviter de créer un Product Backlog surdimensionné dès le départ. Mieux encore, c’est à l’équipe Scrum de les utiliser à bon escient. Voici 8 tactiques pour commencer :

#1 – Adoptez la simplicité

Tenez-vous-en au principe de simplicité du Manifeste Agile, qui implique de maximiser le travail non effectué. Concentrez-vous sur les articles les plus précieux pour offrir la plus grande valeur client et business.

#2 – Limitez les travaux en cours (Work in Progress : WiP)

Limitez le nombre d’éléments dans le Product Backlog à tout moment. La limite WiP peut éviter la surcharge et encourager l’équipe à terminer les objets avant d’en prendre de nouveaux.

#3 – Affinez régulièrement le Product Backlog

Gardez le Product Backlog gérable en organisant régulièrement des sessions d’affinement pour vous assurer que les éléments sont toujours pertinents, précieux et correctement hiérarchisés.

#4 – Affinez juste-à-temps

Évitez de trop affiner les éléments qui ne sont pas imminents pour le développement. Plus un élément est éloigné de la sélection pour un Sprint, moins il devrait être détaillé. L’équipe Scrum ajoute des détails lors des séances de raffinement juste à temps.

#5 – Hiérarchisez et dépriorisez

Acceptez le fait que tous les éléments du Product Backlog ne seront pas implémentés. Établissez régulièrement des priorités et, si nécessaire, supprimez les priorités ou supprimez les éléments du Product Backlog qui ne correspondent plus à l’objectif du produit.

#6 – Responsabilisez les équipes

Encouragez l’auto-organisation au sein de l’équipe Scrum. Donnez-leur les moyens de proposer et de négocier des éléments dans le Product Backlog, renforçant ainsi leur sentiment d’appartenance et d’engagement. Les meilleurs développeurs challengent toujours leurs Product Owners !

#7 – Faites la promotion un dialogue ouvert

Favorisez une culture de dialogue ouvert et de collaboration entre l’équipe Scrum, les parties prenantes et le Product Owner. Encouragez tout le monde à apporter des idées et à remettre en question celles qui existent déjà, en évitant l’effet d’éviction.

#8 – Favorisez l’apprentissage continu et l’adaptation

Adhérez au processus empirique de « transparence, inspection et adaptation » de Scrum. Apprenez de chaque Sprint, adaptez le Product Backlog en fonction des informations, par exemple, de la revue de Sprint (Sprint Review), et soyez ouvert aux changements.

Pour terminer

Le Product Backlog est un outil essentiel dans le développement de produits avec Scrum. Son efficacité est liée à la simplicité, à la limitation du travail en cours, au raffinement régulier, aux détails juste-à-temps, à la priorisation, à l’autonomisation des équipes, au dialogue ouvert et à l’apprentissage continu.

Tous ces principes fonctionnent ensemble pour garder le Product Backlog concentré, exploitable et aligné sur l’objectif du produit, améliorant ainsi la transparence et favorisant une culture de collaboration et d’amélioration continue.

Comment empêchez-vous un nouveau Product Backlog de devenir surdimensionné ?