5 méthodes pour prioriser votre backlog

OUTIL STRATÉGIE AGILE

La priorisation

En tant que Product Owner aguerri, vous n’avez aucun mal à remplir votre backlog d’user stories. En revanche, quand vient le moment de les prioriser, c’est là que ça se corse !

‍

Pas de panique, cet article est fait pour vous. Vous y trouverez 5 méthodes, plus ou moins simple à mettre en place suivant vos objectifs, afin de vous permettre de prioriser vos fonctionnalités & US 😉

‍

MoSCoW (la plus connue)

MoSCoW veut dire littéralement :

• M = Must Have = Vital
• S = Should Have = Essentiel
• C = Could Have = Confort
• W = Won’t Have = Accessoire pour le moment

C’est une méthode qui est simple à mettre en place et facilement compréhensible.
L’objectif est de prioriser les User Stories suivant ce qui doit absolument être fait, devrait être fait, pourrait l’être, à ne pas faire pour le moment (mais à venir).

‍

Pour l’exécution de cette méthode, vous avez différentes options :

• Mettre sur des post-its les US que vous n’arrivez pas à prioriser et faire voter l’équipe pour chacune d’entre elles. Biensûr, mettre une limite au nombre de “must have” afin que les échanges soient efficaces.

• Faire un premier classement de votre côté et valider avec l’équipe ensuite (pour les plus pressés mais je vous conseille la première option).

‍

WSJF (pour les aficionados de SAFe)

WSJF pour dire littéralement :

• W = Weighted
• S = Shortest
• J = Job
• F = First

C’est une méthode de calcul préconisée par le framework SAFe (agile à l’échelle).
Il repose sur le calcul du coût du retard (cost of delay) par rapport à la complexité de réalisation (Job Duration).

‍

Le Cost of delay repose sur l’addition de :

• la Valeur Business pour l’utilisateur
• la criticité (la fonctionnalité doit-elle être livrée rapidement ou non)
• la réduction des risques/facilité pour développer une autre fonctionnalité

Pour attribuer une valeur à chaque élément, on se base sur la suite de Fibonacci : 1,2,3,5,8,13,20.

‍

Le résultat obtenu de cette addition, on le divise par la taille de la fonctionnalité à développer (complexité, effort à fournir par l’équipe de développement pour la réalisation).

‍

Cela nous donne le WSJF par User Story, les US ayant le score le plus élevé seront donc priorisées par rapport aux autres.

N.B : C’est une méthode d’aide à la priorisation mais si vous trouvez certains résultats non représentatifs, libre à vous d’effectuer une nouvelle priorisation. Ce sont des outils d’aide qui peuvent nécessiter une réflexion supplémentaire pour certains contextes.

‍

‍

Kano (pour ceux qui aiment les diagrammes)

C’est la représentation du niveau de satisfaction d’un client face à votre produit.
En effet, un utilisateur peut être moyennement satisfait de la présence d’une fonctionnalité… mais son absence peut être un motif de grande insatisfaction.

Face à ce constat, on construit un diagramme suivant 2 axes :

• Vertical : qui représente le degré de satisfaction du client
• Horizontal : pour le degré de réalisation (ou de présence) d’une fonction/caractéristique/service.

‍

La mise en place de ce modèle se fait en 2 temps :

1. On réalise un atelier avec les parties prenantes afin qu’elles répondent aux questions suivantes :

• Le produit possède cette fonctionnalité, qu’en pensez-vous ? (forme fonctionnelle)
• Le produit ne possède pas cette fonctionnalité, qu’en pensez-vous ? (forme dysfonctionnelle)

Leur réponse doit être formulée par : Aime / Attente / Neutre / Vit avec / N’aime pas, permettant une classification des fonctionnalités

2. Ensuite, on analyse les résultats :

• Les fonctionnalités obligatoires ou essentielles (O) : les bases
• Les fonctionnalités linéaires (L) : l’addition de ces fonctionnalités permet d’augmenter la valeur de votre produit.
• Les fonctionnalités excitantes (E) : le « petit plus »

‍

‍

Score d'opportunité (pour la prise en compte de l'interne)

Dans le même esprit que le WSJF, ce sera également un ratio à calculer. Il permet de calculer le retour sur investissement attendu d’un effort produit, le fameux effort/impact.
La subtilité est qu’il prend en compte l’impact interne. Cela peut être un vrai facteur de décision, en particulier pour les contextes au sein des grandes entreprises.

Il se base sur ces 4 données :

• l’impact utilisateur : dans quelle mesure cette solution résout-elle le problème de l’utilisateur ?
• l’impact interne : dans quelle mesure cette solution aide-t-elle vos collègues à atteindre leurs objectifs ?
• l’impact business : dans quelle mesure cette solution va-t-elle générer des revenus supplémentaires ?
• le coût : quel est l’effort nécessaire ?

Pour chacun de ces critères, il faudra attribuer un score de 1 à 10 : 1 étant un petit effort, et 10 un énorme effort.

Petit conseil : pour simplifier les attributions de score vous pouvez vous limiter à 1–3–7–10 par exemple. Cela permet de mieux visualiser les différences d’effort : petit, moyen, important, énorme.

‍

Enfin, il ne vous reste qu’à additionner les impacts, puis les diviser par le coût et vous obtenez votre score d’opportunité.

La limite : il met les besoins internes et externes au même niveau. Dans de nombreux cas vous créerez plus de valeurs en résolvant un problème pour vos utilisateurs plutôt que vos collègues.

‍

Buy a feature (si vous voulez un atelier ludique)

C’est une variante un peu différente des autres méthodes de calcul car c’est un réel atelier à organiser et animer. Cela demande donc plus de temps de préparation que pour les autres méthodes (mais elle n’en est pas moins efficace !).

Il permet de prioriser les fonctionnalités de la plus importante à la plus accessoire.

Il est simple dans la réalisation avec comme étapes :

1. Convier tous les acteurs du projet
2. Leur distribuer de l’argent (la même somme pour tous). Pour cela il vous suffira d’imprimer différents billets tout en restant dans un budget limité. Par exemple : 2×100, 2×50, 4×20, 4×10.
3. Rendre de manière visible (post-its) les différentes fonctionnalités sur lesquelles ils vont devoir se pencher avec un prix pour chacune. Expliquez-les.
4. Les participants achètent les fonctionnalités.
5. Une fois terminé, on fait les comptes pour voir les fonctionnalités retenues.
6. On débat sur la sélection qui est ressortie et vous avez votre priorisation.

‍

Conclusion

Une méthode n’est pas forcément plus recommandée qu’une autre. Vous n’avez qu’à choisir suivant celle qui vous parle le plus ou encore ne pas choisir et toutes les tester pour varier d’approche lorsque qu’une priorisation s’impose !

‍