Comment prioriser son Product BackLog ?
Comment prioriser son Product BackLog, ça vous parle ? Je ne suis pas envieuse des Products Owners qui ont cette lourde responsabilité. Voir même soulagée. En effet, cette tâche est loin d’être simple et anodine. Mais le rôle d’un Scrum Master, c’est bien d’accompagner l’équipe de développement, mais aussi le Product Owner !
Je pense qu’instinctivement, les PO ordonnancent leurs items (fonctionnalités, epics ou US) par Business Value. C’est la base et c’est plutôt une démarche saine. Maintenant, ce n’est pas toujours suffisant pour être à l’aise et différencier 2 items dont la valeur métier est proche…
Cet article s’inspire grandement de la présentation “Et si votre backlog était au-dessus de la moyenne ?” de Kervin Kueny lors de l’Agi’Lille qui s’est tenu en juin, et de mon expérience “terrain”. Je vous présente quelques méthodes, et mon avis sur chacune.
Priorisation par application de la matrice d’Eisenhower
Cette méthode de priorisation aurait été inspirée par Dwight D. Eisenhower, président des États-Unis, qui aurait dit : “Ce qui est important est rarement urgent, ce qui est urgent rarement important”. Eisenhower était un champion en matière de productivité. Son secret ? Cette matrice, qui permet de prioriser en fonction de deux axes : Importance et Urgence. Ce qui permet de dessiner 4 quadrants distincts :
- Quadrant en haut à droite : les tâches importantes et urgentes,
- Quadrant en bas à droite : les tâches importantes, mais non urgentes,
- Quadrant en haut à gauche : les tâches non importantes, mais urgentes,
- Quadrant en bas à gauche : Les tâches non importantes et non urgentes.
Le cadran urgent+ / importance+ est bien sûr la priorité absolue en termes de traitement. Les tâches qui ne sont ni urgentes ni importantes ne rentrent pas dans les objectifs prioritaires. Elles peuvent même être abandonnées dans le cas où elles sont véritablement inutiles.
Cette classification est applicable dans maints domaines, notamment la priorisation des items d’un Product BackLog.
Priorisation par application de la matrice à double entrée
En atelier avec les stakeholders du produit (utilisateurs, métier/clients, PO, équipe de dev), on passe en revue un par un les items du Product BackLog. Chacun effectue 2 votes : un pour le bénéfice, l’autre pour la simplicité d’implémentation. On fait une moyenne et on positionne l’item sur la matrice.
Arrêtons-nous déjà sur les deux premières méthodes ci-dessus, elles permettent de mettre le pied à l’étrier, mais comment différencier 2 items dans la même “case” ? Si la case est juste cochée “oui, je suis dans cette case”, on arrive alors vite aux limites de cette méthode, avec plein d’items non triés, au même niveau, dans la même case. Il vaut donc mieux alors, pour être plus précis, exploiter au maximum la vue 2D, pour pointer précisément où se situe l’item. Mais cette méthode a ses limites, on peut vite être noyé sous un nuage dense de points…
Priorisation Moscow
Cette méthode de priorisation consiste à placer chaque item dans une catégorie : Must, Should, Could, Won’t, via l’interview des métiers/utilisateurs. La difficulté est que certains interlocuteurs (je pense aux utilisateurs ou au métier) risquent de vouloir tout mettre dans la catégorie must… Une astuce est de rajouter une colonne “super must” devant contenir les items plus qu’incontournables, et de demander à l’interlocuteur d’y placer les items adéquats…
Priorisation par détournement de la matrice AMDEC
La matrice AMDEC sert initialement à gérer les risques. Elle a été créée par l’armée américaine dans les années 40. L’AMDEC est à l’origine une méthode utilisée dans la gestion de la qualité. Elle sert aujourd’hui dans l’identification des risques d’un projets et les mesures à prendre pour les réduire. AMDEC signifie, littéralement « Analyse des Modes, des Effets et de la Criticité des défaillances » (traduction de l’anglais FMECA : Failure Modes, Effects and Criticality Analysis). Comme beaucoup de méthodes de priorisation, celle-ci est apparue dans les années 40 dans l’armée américaine, puis a été utilisée dans l’aéronautique.
S’appuyer sur la fréquence d’utilisation (exemple : fréquence d’utilisation par an) et l’impact sur les utilisateurs (combien d’utilisateurs sont concernés) sont des critères non utilisés dans les autres méthodes citées dans cet article, alors qu’ils semblent totalement pragmatiques et pertinents !
Pour utiliser les méthodes ROI et WSJF détaillées ci-dessous, il faut tout d’abord se mettre d’accord sur le référentiel de valeurs possibles à accorder à chaque critère. De mon côté, je privilégie les valeurs de la suite de Fibonacci pour évaluer la complexité (c’est ce que nous utilisons au quotidien dans l’équipe pour évaluer nos Users Stories). Parcontre, pour les valeurs de Business Value, d’urgence à faire et de risque/opportunité, je préfère utiliser les chiffres de 0 à 10 (ou les multiples de 10 de 0 à 100, ou les multiples de 100 de 0 à 1000). Le résultat est plus précis que si on utilise la suite de Fibonacci avec laquelle on va avoir du mal à poser une note supérieure ou égale à 13… Les valeurs de taille de Tee-shirts (S, M, L, XL) ne permettant pas de faire des calculs mathématiques, je les évite.
Priorisation par le ROI
La méthode est simple et relativement efficace.
Priorisation par l’utilisation de la méthode WSJF de SAFe
SAFe est un ensemble de modèles d’organisation et de processus destiné à déployer à grande échelle les méthodes Agile et Lean. SAFe tente de répondre à la problématique des grandes organisations qui souhaitent faire travailler ensemble plusieurs équipes agiles.
WSJF est une méthode de priorisation du Product BackLog signifiant “Weighted Shortest Job First” (ou en français “la plus importante ou la plus courte fonctionnalité d’abord”).
Il repose sur le calcul du Coût à ne pas faire (cost of delay) par rapport à la complexité de réalisation (Job Duration).
Le Coût à ne pas faire repose sur l’addition de la Valeur métier pour l’utilisateur + l’Urgence à faire/criticité (la fonctionnalité doit-elle être livrée rapidement ou non) + la réduction des risques / la facilité pour développer une autre fonctionnalité
Même si je ne suis pas totalement convaincue par Safe, je trouve que l’outil WSJF est plutôt bien rodé : il est assez similaire à la méthode du ROI, en intégrant en plus la détermination si l’item doit être livré rapidement ou non (time criticality) et la détermination si cet item réduit le risque ou facilite le développement d’autres items par la suite (risk reduction / opportunity enablement). Ça en fait du coup un outil assez complet. C’est pourquoi c’est ma méthode préférée.
Les deux dernières méthodes de priorisation ont une limite : les items ayant une forte valeur métier, mais aussi une forte complexité risquent de ne jamais passer, au contraire des quick-wins. Hors il peut s’avérer dommageable de ne jamais laisser passer les items qui ont certes une complexité importante, mais surtout une valeur métier importante. Une solution toute simple est de spliter ces items en sous-items, afin de recalculer le score de priorité de chaque sous-item. Et là on peut remonter à une priorité haute certaines fonctionnalités importantes, mais tombés tout en bas du classement du fait de leur complexité haute…
Toutes ces méthodes sont intéressantes, certaines trouveront peut-être grâce à vos yeux, l’essentiel pour moi est d’utiliser celle.s qui vous convienne.nt comme des outils d’aide à la décision et de prémâchage, pas d’en suivre une stricto senso sans remettre en cause le résultat…
Références
https://www.manager-go.com/efficacite-professionnelle/dossiers-methodes/matrice-eisenhower
http://talentagile.com/comment-prioriser-son-product-backlog-a-laide-du-wsjf/
https://fr.wikipedia.org/wiki/Scaled_agile_framework
https://www.lescahiersdelinnovation.com/la-methode-amdec-analyse-des-risques/
5 méthodes pour prioriser votre backlog
Perrine Maroye, Scrum Master, Xpeho
