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 veut dire littéralement :
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 :
WSJF pour dire littéralement :
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 :
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.
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 :
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 :
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 :
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 :
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.
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 :
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 !