Et si vous réduisiez un peu votre Product Backlog avant de partir en congés ?

Avec trop d'articles dans le Product Backlog, 3 problèmes majeurs se manifestent :

1. L'équipe à l'impression de faire du « sur place » ou d'être face à une montagne infranchissable. À chaque itération (Sprint), l'équipe de développement et ses clients remarquent à peine le progrès réalisé. Une équipe qui finit 10 items ou User Stories sur 50 de son product backlog ressent bien qu'elle a avancé. Elle n'a aucun doute sur ce fait. Une équipe qui finit les mêmes 10, mais sur 500 articles n'a pas la même sensation d'accomplissement. Ses membres commencent à se demander quel serait l'impact s'ils n'avaient réalisé que 8 ou 9 au lieu de 10 articles.
2. Ensuite, il est plus difficile de travailler avec un Product Backlog excessivement long. Avec un très gros Product Backlog, tous les membres de l'équipe et parties prenantes perdent beaucoup de temps à chercher des items ou User Stories. “Je me rappelle l'avoir vu, je sais que c'est ici quelque part dans le Product Backlog.” Des doublons ne vont pas manquer d'être créés car il devient plus facile d'ajouter une User Story « au cas où » quand on n'arrive pas à la retrouver. De plus, poser les bonnes priorités (et les revoir régulièrement) sur un long Product Backlog va nécessiter énormément de temps et d'efforts.
3. Enfin, quelqu'un a dépensé du temps de valeur à créer tous ces items du Product Backlog. Si donner de la visibilité sur le futur du produit est intéressant, se projeter trop loin dans l'avenir est une perte de temps et un gaspillage d'efforts. Les choses vont immanquablement changer au fil du temps : les priorités de l'entreprise et des clients, l'écosystème, l'industrie, les technologies, les ressources... Quel est le bon horizon de temps pour votre projet dépend de nombreux facteurs mais trop de Product Backlogs essaient de fournir une visibilité bien trop lointaine dans l'avenir de leur produit. En fait, n'oubliez pas que l'un des plus gros avantage des approches Agiles est de livrer le plus tôt possible ce qui apporte le plus de valeur et de s'arrêter dès que la valeur incrémentale d'items de moindre priorité ne justifie plus l'investissement.

Comme ces problèmes liés à un Product Backlog excessivement long peuvent être tellement nuisibles, regardons plusieurs choses que vous pouvez faire pour le maintenir à une taille plus gérable.

N'ajoutez rien que vous ne planifiez de faire très très prochainement

Ne chargez pas trop la barque. Soyez disciplinés et n'ajoutez aucun article au Product Backlog à moins que vous n'ayez résolument l'intention de faire. Et de le faire prochainement. Rien ne sert de faire entrer dans le Product Backlog des items dont vous aurez probablement besoin dans 2 ou 3 ans. Cet horizon de temps n'est pas celui de l'équipe de développement qui est focalisée sur les quelques itérations à venir.

Un autre aspect est que la plupart des Product Backlog grossissent trop parce qu'il est plus facile pour le propriétaire de produit de dire “je vais le mettre dans le Product Backlog” que de dire à quelqu'un « ta demande ne sera jamais traitée ».

Pour garder leur Product Backlog en bonne santé, les propriétaires de produit doivent apprendre à dire non dès aujourd'hui.

Soyez extrêmement clairs sur les priorités

Utilisez une Structure de Priorisation qui vous aidera à promouvoir l'alignement et éviter les conflits pendant les discussions.

Les structures de priorisation de produit vous donnent une façon de décider sur quoi travailler ensuite. Il y a pléthore d'approches dans lesquelles piocher. Choisissez celle qui marche le mieux avec votre équipe projet et vos parties prenantes.

Une des structures les plus simples pour utiliser est la matrice Valeur sur Complexité. Vous créez un diagramme avec la valeur en axe des ordonnées et la complexité en abscisses. Puis, divisez le diagramme dans quatre quadrants et positionnez-y les items.

• Forte valeur, faible complexité: Une différence significative pour un effort minimal
• Forte valeur, forte complexité : Beaucoup de valeur mais exigent plus de temps, ressources, argent
• Faible valeur, faible complexité: Agréable à avoir, mais vous pouvez vivre sans
• Faible valeur, forte complexité : à éviter.

D'autres approches plus complexes que vous pouvez considérer :

• La méthode la plus répandue : MoSCoW (Must-Have, Should-Have, Could-Have, Won't-Have)
• Le modèle de Kano
• Le Weighted Scoring Prioritization
• Le Weighted short job first

Supprimez les choses que vous ne ferez jamais

Donc, un premier conseil, supprimez les items / User Stories que vous savez bien que vous ne ferez jamais.

Je sais d'expérience combien cet exercice est difficile... Mais ce n'est pas parce que c'est difficile que ce n'est pas faisable.

En fait, ce serait plutôt le contraire. Plus vous ferez fréquemment cet exercice et moins il sera pénible. Vous allez bien sûr parfois vous tromper et devrez recréer des User Stories. Mais en général, je constate qu'elles sont alors plus précises, plus spécifiques, plus ciblées. Donc, n'ayez plus de crainte d'éliminer une chose qui reviendra peut-être. Vous pouvez avec l'équipe écrire une meilleure histoire plus tard si réellement nécessaire.

Soyez assez impitoyables dans l'élimination d'items de votre Product Backlog. Si d'un point de vue réaliste, vous ne pensez pas que vous le ferez jamais, débarrassez-vous en.

Sinon, votre Product Backlog va accumuler de plus en plus d'arriéré au fil du temps au lieu de se réduire au rythme des itérations de développement et livraisons aux clients.

Passez régulièrement (trimestriellement) en revue l'ensemble du Product Backlog

Cette revue trimestrielle qui vous permet de tenir votre Product Backlog à une taille raisonnable doit être sanctuarisée en un processus régulier. Rien de neuf ici, si ce n'est de le faire.

En pratique, le propriétaire de produit peut se programmer une session de passage en revue du Product Backlog produit et supprimer des articles comme décrit ci-dessus.

Tous les mois serait probablement trop coûteux et semestres trop long.

Prévoyez un petit « réservoir à idées »

Rangez-y les quelques items que vous considérez critiques mais sur lesquels vous n'êtes pas prêts à investir maintenant. Vous ne voulez pas les perdre de vue mais ce sont des sujets qui ne sont pas tout à fait prêts ou pourraient ne pas s'avérer nécessaires au final.

Le Product Backlog contient toutes les choses pour lesquelles le Product Owner est prêt à payer rubis sur l'ongle pour les avoir dès ce soir si cela était possible.

Le réservoir contient au contraire des choses que le propriétaire de produit voudrait probablement, mais n'a pas réfléchi assez dans le détail ou peut-être pas nécessaire après tout.

Essayez cette approche extrêmement utile car elle vous apporte une réduction immédiate de la taille du Product Backlog comme vous déplacez provisoirement les items vers un autre endroit.

En résumé, dans le Product Backlog, toutes les User Stories pour lesquelles le propriétaire de produit paierait l'équipe dès ce soir pour les livrer; Dans le « réservoir à idées », tous les autres besoins qui pourraient changer ou ne sont pas encore bien compris.

En pratique, créez un autre projet avec son backlog pour le réservoir de manière à ne pas « polluer » le Product Backlog sur lequel travaille l'équipe.

Ceci va permettre à l'équipe de se concentrer sur un panel beaucoup plus petit d'items qui forment leur Product Backlog.

Et ajoutez alors sans aucun remord les User Stories qui le méritent

Comme certains items sont finis, ils sont automatiquement sortis du backlog en cours de développement. Les suivants qui ont la plus forte importance remontent dans la liste, prêts à être embarqués sur de prochaines itérations.

Comme la force de l'agilité est la capacité à s'adapter à un environnement en perpétuel changement, il est aussi normal et souhaitable que de nouvelles user stories entrent dans le Product Backlog si les conditions mentionnées ci-dessus sont réunies. Le propriétaire de produit aura pris soin au préalable de bien considérer et évaluer le potentiel bénéfice de celles-ci et leur temporalité.

Il est critique que le product owner réunisse toutes ses parties prenantes en amont pour qu'elles discutent et s'alignent les unes avec les autres sur le "quoi", "pourquoi" et "comment" pour avoir une vue la plus complète possible du besoin. Les rassembler (en personne ou virtuellement) fera gagner à chacun beaucoup de temps et évitera de la déperdition de contenu et de valeur dans des chaines à rallonge de courriers électroniques.