Prioriser son product backlog de manière efficace

Après avoir rédigé les user stories, l'un des plus gros challenges pour un Product Owner est de prioriser par la valeur son backlog. Comment savoir par quelles US commencer et déterminer un ordre d’importance pour chacune d’entre elles ? C'est certain, le premier critère de priorisation pour un Product Owner sera toujours la VALEUR, c’est à-dire le bénéfice que va apporter cette US à l’entreprise et/ou à l'utilisateur.  

Mais est-ce le seul élément à prendre en compte dans la priorisation d'un backlog ? Que fait-on alors des risques, de l'adéquation à la stratégie de l'entreprise ou encore de l'effort que va demander le développement de chaque user story ?

Alors, quelle méthode employer ? Nous te présentons ici 2 outils parmi d'autres (RICE, KANO,...) qui, selon nous, ont fait leurs preuves dans la construction et l'amélioration de nombreux produits et nous te guidons sur leurs écueils et la manière de les utiliser.
‍

Pourquoi prioriser son backlog ?

• Mieux investir ses ressources en développant les fonctionnalités les plus utilisées et génératrices de valeur pour l'entreprise et en maîtrisant le budget et les délais
• Livrer le plus fréquemment possible des incréments du produit en production, directement exploitables et testables par les utilisateurs  
• Mieux gérer les risques inhérents au produit, grâce à la communication entre les parties prenantes  

MOSCOW, une première clé pour une priorisation efficace

Nous n'allions tout de même pas passer à côté du grand classique qu'est la méthode  MoSCoW . Tu la connais sûrement déjà, mais une petite piqûre de rappel est toujours la bienvenue.

La méthode MoSCoW, mise au point par le consultant Dai Clegg est un outil très utilisé dans les projets Agile. En effet, son principe est d'aller plus loin que la simple notion "d'importance". C'est également, un très bon moyen d'aligner la vision des différentes parties prenantes sur les tâches prioritaires à réaliser par l'équipe produit. Cette technique permet de prioriser les user stories selon 4 niveaux de criticité :  

• M(o) — Must have :  il faut mettre dans cette catégorie uniquement les pré-requis ou les fonctionnalités indispensables au projet, c’est-à-dire les éléments sans lesquels le produit ne peut pas être déployé en production. Ces éléments doivent absolument être développés, sans eux, le produit est un échec.  
• S — Should have :  les éléments importants et qui apportent énormément de valeur au produit final mais sans lesquels le produit peut être déployé en production. Ces fonctionnalités seront développées une fois que celles de la catégorie “Must” sont déployées et si les délais et le budget le permettent.  

• C(o) — Could have :  il s’agit ici de user stories dites "de confort", à réaliser uniquement si cela n’a pas d’impact sur d’autres tâches et que le temps le permet. Il s’agit de “petits plus” qui contribuent à augmenter la satisfaction des utilisateurs.
• W — Won’t have : this time but would like in the future :  ces tâches ne seront pas réalisées immédiatement mais restent souhaitables afin d’améliorer le produit dans le futur.  

Attention à ne pas tomber dans le piège du “tout est important”. Avec cette méthode, on peut facilement avoir une grande quantité de “MUST” et/ou de “SHOULD” qu'il est ensuite difficile de départager.  

Les limites de la priorisation avec l’outil MoSCoW :

• Cette méthode ne prend pas en compte la composante du temps. Certaines fonctionnalités peuvent mettre beaucoup plus de temps à être développées que d’autres, ce qui peut être potentiellement bloquant pour d’autres releases.  
• Il n’y a pas de critères objectifs permettant de trancher facilement entre plusieurs fonctionnalités de la même catégorie.  

Afin de répondre à ces problématiques et aller plus loin dans la priorisation du backlog, une autre méthode peut être utilisée.
‍

WSJF, pour aller plus loin dans la priorisation de son backlog

Le WSJF ("Weighted Shortest Job First" ou "Le travail le plus lourd et le plus court en premier") est une technique issue du framework SAFe. Cette méthode permet de prioriser le backlog d’un produit de manière impartiale en trouvant le bon équilibre entre la valeur et l'effort de travail. Elle se base notamment sur le concept de “Cost of delay” (CoD).Le coût du retard part du principe que toute fonctionnalité non livrée à temps a un coût.  

En effet, dans la philosophie Lean, l’objectif premier est de réduire ce coût du retard au minimum afin d'augmenter l'efficacité et livrer le maximum de valeur à l’issue d’un Sprint.  

Les critères à prendre en compte  

Pour le calcul du CoD ou CD3 (littéralement Cost Of Delay Divided by Duration), il est nécessaire de prendre en compte les critères suivants pour chaque US/item :  

• User-Business Value :  la valeur métier de l’US / de la fonctionnalité  
• Time Criticality : la criticité, c’est à dire est-ce que la fonctionnalité doit être mise sur le marché rapidement ou non ?
• Risk Reduction and or Opportunity Enablement :  est-ce que l’implémentation de cette fonctionnalité peut engendrer des opportunités pour développer facilement d’autres fonctionnalités ? Est-ce que cette fonctionnalité permet de réduire des risques liés au produit ?  
• Job size : l’effort nécessaire pour développer la fonctionnalité, la taille de la fonctionnalité à développer. Cet élément peut être estimé par l’équipe de développement lors du backlog refinement.  
  

Calculer le coup du retard  

Une fois l'estimation de ces 3 critères faite pour chaque élément du backlog, il suffit d’additionner ces 3 éléments pour obtenir un résultat que l’on va appeler le "Coût du retard".  

Cost of delay = User-Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement

Calculer le travail nécessaire du WSJF  

Maintenant que le coût du retard a été calculé, il faudra, pour chacune des US à prioriser, estimer l'effort de travail nécessaire. Cette dernière opération nous permettra de calculer le WSJF.  

Lorsque tu as obtenu la valeur de ton WSJF, le principe est simple :  plus la valeur du WSJF est élevée, plus l’item est prioritaire.  

Attention, le CoD (Cost of Delay) n’est pas figé dans le temps !  En effet, plus le projet va évoluer dans le temps, plus le niveau de criticité va augmenter.  Par conséquent, le calcul du CoD  risque de changer et donc du WSJF.  

L'unité de valeur à utiliser pour le calcul du WSJF n'est pas forcément l'euro ! Tu peux très bien utilisez des jours/homme, des minutes ou encore des story points etc... N'hésite pas à jeter un oeil à cet exemple imagé et détaillé du calcul du WSJF appliqué à notre quotidien.  

En conclusion, il est important de prioriser son backlog afin de pouvoir commencer par les tâches ayant le plus de valeur pour l’utilisateur en premier. Néanmoins, en fonction de l’outil utilisé, des paramètres comme le temps ou le coût que représente le retard de livraison sont oublié. Pour cela, il est judicieux de pouvoir choisir celui qui te convient en fonction de la maturité du produit et de ton équipe.

‍

Ce qu'il faut retenir pour bien prioriser son backlog

• La valeur n'est pas le seul critère à prendre en compte pour la priorisation de ton backlog.
• Gardez en tête tes objectifs : livrer le plus fréquemment possible des incréments utilisables en production.  
• La criticité est un bon critère pour commencer la priorisation de ton backlog mais ce n'est que la première étape !
• Le WSJF est une technique de priorisation du backlog impartiale qui permet de trancher rapidement entre plusieurs items.