Prioriser son backlog de manière efficace

prioriser un backlog

Après avoir rédigé les User Stories, un des plus gros challenges pour un Product Owner se trouve souvent dans le fait de prioriser son Backlog

Comment savoir par quelle 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 ? On vous présente 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 on vous guide 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 en maîtrisant budget et délais

Livrer le plus fréquemment possible 

des incréments du produit en production, directement exploitables 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. Vous la connaissez 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 outils très utilisé dans les projets Agile. En effet, son principe est d’aller plus loin que la simple notion « d’importance » et 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 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. 
  • 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ère objectif capable de faire 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 backlogune autre méthode peut être utilisée. 

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

LWSJF (« 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 travailElle se base notamment sur le concept de Cost of delay” (CoD), littéralement, le coût du retardqui 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

Calculez votre 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. 

calcul du WSJF

Lorsque vous avez obtenu la valeur de votre WSJF, le principe est simple : plus la valeur du WSJF est élevée, plus l’item est prioritaire

  • Attention, le COD n’est pas figé dans le temps ! En effet, plus le projet va évoluer dans le temps, plus le niveau de criticité va augmenter ce qui risque de changer le calcul du CoD et donc du WSJF. 
  • L’unité de valeur à utiliser pour le calcul du WSJF n’est pas forcément l’euro ! Vous pouvez très bien utilisez des jours/homme, des minutes ou encore des story points etc…
  • N’hésitez pas à jeter un oeil à cet exemple imagé et détaillé du calcul du WSJF appliqué à notre quotidien.

Ce qu'il faut retenir pour bien prioriser son backlog

Article écrit avec passion par Anne.

Cet article vous a plu ? N’hésitez pas à le partager autour de vous !

De la veille Product & Quality Management ça vous intéresse ? 

Vous pouvez dès maintenant suivre WeFiiT sur Linkedin pour en bénéficier.

Vous voulez en savoir plus ? Jetez un œil à nos autres articles :

Partager sur linkedin
Partager sur twitter
Partager sur email