9 Frameworks de priorisation #3 : Les approches avancées

Cet article sur les frameworks de priorisation est composé de plusieurs parties, si vous arrivez depuis la 2e partie de cet article, merci de nous avoir suivi jusqu’ici. Sinon vous pouvez également retrouver nos 2 premières parties :
Part 1 – Comment choisir son framework de priorisation parmi 9 methodes
Part 2 – 9 framework de priorisation – Approches simples


On attaque dans cette troisième partie de l’article des méthodes de priorisation avec des approches plus avancées. Si vous êtes à la recherche de frameworks qui vous permettent de pousser votre réflexion, vous êtes au bon endroit.



Contrairement à la première partie où les approches pouvaient se faire rapidement et seul ou en équipe réduite avec peu d’input, nous allons vous présenter des méthodes qui demandent plus de préparation, plus de data et qui prendront plus de temps à être implémentées.



Pour rappel, nous verrons ici les frameworks suivants :

5. Story mapping
6. Buy a feature
7. ICE & RICE
8. Weighted Shortest Job First
9. Opportunity scoring

5. Story mapping

Un framework de priorisation assez répandu. Il est plutôt orienté expérience utilisateur que les avis et opinions de l’équipe et/ou des stakeholders.


Sur une ligne horizontale sont listées des features ou des sujets (des épiques par exemple) qui peuvent représenter toutes les étapes d’un parcours utilisateur sur votre produit. Cette approche permet de raisonner comme un utilisateur.



Sous chacune des colonnes, vous pouvez lister les fonctionnalités qui correspondent à chacun des sujets et vous pourrez les classer par ordre de priorité. Pour finalement délimiter vos sprints, releases ou par exemple votre MVP.

Quand l’utiliser :

Permet de rapidement déterminer un MVP de produit ou de featurePermet une approche très orientée expérience utilisateur
Facilement adaptable pour de la collaboration
Inclus un aspect de dépendance entre des fonctionnalités

Ses limites :

Il ne tient pas compte de facteurs externes comme la valeur et la complexité

6. Buy a feature

C’est un jeu d’innovation qui permet d’inclure des utilisateurs ou des stakeholders dans l’exercice de priorisation. Il permet d’estimer la valeur d’une fonctionnalité pour ces derniers.

Le principe est le suivant :

Sélectionner une liste de fonctionnalités ou idées auxquelles on associe une valeur monétaire. Cette valeur monétaire est basée sur l’effort global de réalisation (temps, argent, effort) pour l’équipe.Réunir un groupe de personnes (8 max de préférence) qui auront un budget à dépenser sur ces fonctionnalitées
Demandez leur de dépenser leur budget (sur une ou plusieurs fonctionnalités) et d’expliquer leurs choix
Réorganiser les fonctionnalités par ordre de dépense


Astuce : faites en sorte que le prix de certaines fonctionnalités dépasse le budget individuel, cela permettra aux participants de négocier entre eux pour s’associer sur certains besoins.

Quand l’utiliser :

Quand vous souhaitez avoir une idée directe du besoin de vos utilisateurs. Vous animerez mais surtout écouterez leurs discussions qui vous informeront en détails sur leurs besoins et les raisons qui les animent.Bien plus ludique qu’un questionnaire classique
Force vos utilisateurs ou stakeholders à expliquer leurs besoins

Ses limites :

Cette méthode permet essentiellement d’inclure des fonctionnalités déjà prévues dans la roadmapLa valeur monétaire initiale d’une fonctionnalitée demande pas mal de préparation en amont
Il peut être difficile de regrouper plusieurs utilisateurs ou stakeholders à un même endroit au même moment – même si désormais Miro est votre meilleur ami

7. ICE & RICE

RICE et sa variante plus simplifiée ICE (sans inclure le reach) est un framework de scoring très objectif.


Trois critères qualifiants les features sont associés :

Reach : Le nombre d’utilisateurs impactés par la feature
Impact : Le niveau d’impact par utilisateur
Confiance : Calculée en pourcentage sur la confiance des valeurs précédentes


Ensuite ce score est divisé par l’Effort nécessaire pour réaliser la feature. Pour rendre les choix plus simples vous pouvez choisir un chiffre pour Faible/Moyen/Important. Soit 1/2/3 ou utiliser la suite de Fibonacci pour pondérer l’incertitude grandissante avec l’effort.



Une fois le score calculé pour chacune de vos fonctionnalités, il vous sera facile de les classer et de les prioriser.
‍

Quand l’utiliser :

Pour avoir une approche scientifiquePour tenir compte de la portée (reach) d’une feature
Quand l’impact est un facteur important
Utilisé pour intégrer une composante de ressenti d’équipe avec la confiance

Ses limites :

Les facteurs de scoring sont prédéfinis et rendent le modèle très génériqueLe modèle de notation de chaque critère est subjectif
Ne tient pas compte de l’impact inter-fonctionnalités

8. Cost of Delay et Weighted Shortest Job First (WSJF)

Tiré du Lean management, le Cost of Delay ou en français “Coût de retard” est un metric qui représente l’impact économique du retard sur la réalisation d’un projet ou pour nous d’un produit.


Si en plus on divise ce coût par l’effort de réalisation on se retrouve avec le Weighted Shortest Job First, soit le plus petit incrément sur lequel il faudrait travailler en premier.



En créant un tableau similaire à celui ci-dessous vous pourrez rapidement voir la fonctionnalité la plus intéressante à traiter immédiatement.

Le score le plus élevé sera à prioriser en premier. On commencera donc ici par la feature B.



Rémi nous avait d’ailleurs fait un super Wi-binar sur Comment prioriser un backlog grâce à la méthode WSJF ? N’hésitez pas à y jeter un œil pour rentrer plus en détails sur cette méthode.

Quand l’utiliser :

Très utile sur de la priorisation de petits incrémentsPratique pour quantifier les fonctionnalités d’un point de vue monétaire
Permet une approche orientée valeur pour l’entreprise
Permet une approche plus orientée vitesse et valeur en opposition d’un mindset autour du coût et de l’efficacité

Ses limites :

Le coût du retard est très subjectif et pas toujours basé sur des valeurs précises ce qui peut entraîner des désaccords dans les parties prenantesNécessite beaucoup d’effort et est relativement difficile à expliquer à une équipe

9. Opportunity scoring

Issu du concept Outcome-Driven Innovation de Anthony Ulwick, ce modèle compare l’importance d’une fonctionnalité avec la satisfaction de l’utilisateur. Sa théorie réside dans l’idée que les consommateurs achètent des produits pour réaliser des tâches.


L’opportunity scoring, utilise un graphique qui mesure et classe les opportunités de réaliser des tâches pour nos utilisateurs. Après avoir fait une liste d’opportunités, vous interviewez vos utilisateurs pour répondre à deux questions :

A quel point le résultat de la fonctionnalité est important?
A quel point sont-ils satisfaits avec les solutions actuellement sur le marché?


Une fois le score pour la satisfaction et l’importance récolté, vous placez des points sur un graphique avec les deux valeurs en abscisse et en ordonnée ce qui vous permettra de classer les solutions dans 3 catégories :

Sur-servis
Correctement servis
Sous-servis


Vous pourrez vous concentrer sur la catégorie des sous-servies pour avoir le plus fort impact.

Quand l’utiliser :

Pour rapidement identifier les solutions les intéressantes et innovantes pour une problématiquePour visualiser de manière très graphique une priorisation

Ses limites :

Nécessite une forte implication des utilisateursPossible d’influencer les utilisateurs selon la méthode d’administration du questionnaire

C’est la fin de notre série !

Vous êtes arrivés à la fin de notre série sur les frameworks de priorisation. Bravo pour ceux qui nous ont lu jusqu’ici et qui nous ont suivi depuis le début. Si c’est le premier article de la série que vous avez suivi, nous vous invitons à lire les 2 premières parties de la série :
Part 1 – Comment choisir son framework de priorisation parmi 9 méthodes
Part 2 – 9 framework de priorisation – Approches simples


Vous pourrez y retrouver des approches plus simples de priorisation, qui pourraient vous être utiles si le temps de préparation est limité ou si vous souhaitez prendre une décision rapide sans réunir beaucoup de data ou beaucoup de parties-prenantes.

Si vous êtes dans le doute sur le choix de la bonne approche pour votre situation, vous pouvez revenir à notre première partie pour quelques conseils sur vos choix de frameworks.

‍