5 méthodes pour prioriser efficacement en agile

La priorisation est un pilier essentiel de l’agilité et un exercice stratégique complexe à fort impact économique. 

Dans nos organisations agiles où il est crucial de maximiser la valeur produite, la maîtrise des méthodes de priorisation est une compétence essentielle.

Cet article vise à outiller les Product Owner, Product Manager et les directions d’entreprise pour les aider à prendre des décisions robustes et éclairées. 

Nous vous proposons d’explorer 5 méthodes éprouvées pour apporter de la transparence, de l’alignement et remporter l’adhésion autour de la priorisation.

Il n’existe malheureusement pas de formule magique permettant de prioriser de manière optimale les fonctionnalités d’un backlog. 

Chaque méthode est un simple outil d’aide à la décision. En connaître plusieurs aide à prendre les meilleures décisions possibles.

Pourquoi la maîtrise de la priorisation est-elle cruciale ?

Contrairement à un développement en cascade où la livraison de valeur se fait en une fois à la fin du projet, l’agilité est basée sur des cycles courts qui nécessitent de prioriser régulièrement.

Chaque cycle court permet la livraison d’un nouvel incrément de valeur et un retour d’informations rapide sur la valeur délivrée.

La valeur marchande d’une fonctionnalité est maximale au moment où le besoin d’avoir cette fonctionnalité est exprimé.

Bien souvent, cette valeur marchande décroît dans le temps parce que les hypothèses de départ évoluent (besoin mouvant, marché en tension, concurrence accrue). 

L’ordonnancement optimal des fonctionnalités conjugué à la livraison incrémentale sont les deux leviers indispensables permettant aux fonctionnalités d’atteindre les utilisateurs au bon moment.

Une mauvaise priorisation peut entraîner de lourdes conséquences économiques, notamment dans le cadre de l’agilité à l’échelle.

Par exemple, vous êtes aux commandes du Product Management d’un dispositif travaillant en agilité à l’échelle.

Vos choix de priorisation effectués lors d’un PI Planning donnent une orientation à des travaux qui représentent un investissement de plusieurs millions d’euros (100 personnes x 60 jours ouvrés x TJM moyen à 500 € = 3 millions d’euros).

Dans la suite de cet article, nous vous proposons d’explorer les méthodes Story Mapping et MoSCoW qui permettent une priorisation macroscopique. Puis nous verrons comment affiner la priorisation avec les méthodes ROI, WSJF et RICE.

Prioriser avec le Story Mapping

Le story mapping est un outil de pilotage visuel permettant de placer l’expérience utilisateur au cœur du processus de développement, tout en gardant une vision claire des objectifs à atteindre.

1) Qu’est-ce que le Story Mapping ?

Le Story Mapping a été développé par Jeff Patton pour répondre à une problématique fréquente dans les projets : la difficulté à garder une vision globale tout en avançant de manière itérative avec une méthode agile de type Scrum.

À l’inverse d’un backlog classique, linéaire et peu visible, le story mapping permet de raconter l’histoire complète de l’utilisateur interagissant avec le produit.

Elle consiste à organiser les fonctionnalités, de façon structurée et lisible, en les plaçant sur :

• un axe horizontal représentant le parcours utilisateur, 
• et un axe vertical illustrant leur niveau de priorité.

Le Story Mapping est avant tout un outil collaboratif, utilisé lors d’ateliers regroupant les différents acteurs d’un projet, comme :

• le Product Owner,
• les développeurs,
• les UX designers,
• les testeurs,

mais aussi : 

• les clients, 
• les utilisateurs
• et les représentants métiers.

Voyons maintenant quelles sont les 3 étapes à suivre pour concevoir une Story Map.

2) Connaître les utilisateurs cibles

Avant tout, il est indispensable d’apprendre à connaître les utilisateurs cibles, notamment à l’aide d’ateliers organisés pour échanger avec les usagers finaux de l’application développée.

Grâce à ces échanges, des « personas » sont constitués : il s’agit de profils fictifs, mais réalistes, représentant une catégorie d’utilisateurs.

Le persona décrit les objectifs, les frustrations, le comportement digital et les attentes vis-à-vis des produits numériques.

Imaginons une application de réservation de chambres d’hôtel.

Les gérants d’hôtels représentent une première catégorie d’utilisateurs de l’application.

Ils peuvent par exemple :

• proposer des chambres disponibles, 
• définir une politique tarifaire,
• être prévenu par SMS lorsqu’un client a réservé une chambre. 

Les clients qui recherchent une chambre d’hôtel constituent une deuxième catégorie d’utilisateurs de l’application.

Lyna est une personne fictive (persona), inventée pour les représenter :

3) Identifier les fonctionnalités

Les fonctionnalités décrivent des actions précises que l’utilisateur doit pouvoir réaliser.

Une bonne pratique est de décrire chaque fonctionnalité au format User Story, une approche centrée utilisateurs :

En tant que (persona), … je veux (action) … afin de (impact) …

Ce pattern permet de cibler la catégorie d’utilisateurs concernée (persona), de comprendre le besoin exprimé (action) et de mesurer la valeur métier escomptée (impact).

Idéalement, chaque fonctionnalité peut être développée indépendamment les unes des autres de manière à pouvoir reprioriser le backlog tout au long du projet.

4) Prioriser les fonctionnalités

Pour prioriser les fonctionnalités, il convient de les organiser de haut en bas, du plus nécessaire au moins nécessaire, pour chacun des personas de l’application.

La lecture de la Story Map de gauche à droite et de haut en bas doit raconter une histoire cohérente en termes d’interactions entre les différents utilisateurs et l’application.

Prioriser avec la méthode MoSCoW

La méthode MoSCoW permet de compléter l’exercice de Story Mapping pour hiérarchiser les fonctionnalités.

1) Qu’est-ce que la méthode MoSCoW ?

La méthode MoSCoW (Must, Should, Could, Won’t) consiste à classer les fonctionnalités en 4 catégories, selon leur importance perçue :

• Must : fonctionnalités prioritaires à implémenter obligatoirement puisqu’elles sont indispensables à la réussite du projet. Pour savoir si une fonctionnalité entre dans cette catégorie, il faut se demander si l’application est toujours viable sans elle.
• Should : fonctionnalités non obligatoires mais qui apportent une valeur ajoutée à votre projet. Le développement de celles-ci se fait uniquement après les fonctionnalités « Must ». Dans le cas où le temps ne permet pas de les effectuer, cela n’a pas d’impact sur l’atteinte de votre objectif.
• Could : fonctionnalités pouvant être modifiées. S’il y a des choix à faire, supprimer ces fonctionnalités est une bonne option. Sachez toutefois qu’elles apportent une touche finale à votre projet pour optimiser son succès.
• Won’t : fonctionnalités à bannir. Cependant, leur exécution dans le futur permet d’obtenir un rendu final plus satisfaisant.

Bien que simple à mettre en œuvre, cette méthode repose largement sur la subjectivité des parties prenantes. 

Nous verrons plus loin dans cet article que d’autres méthodes s’appuient sur des critères chiffrés et une formule claire. Ce qui réduit l’influence des opinions et facilite une priorisation plus objective.

Le piège le plus courant avec la méthode MoSCoW est de mettre toutes les fonctionnalités dans la catégorie Must, ce qui revient à ne pas prioriser.

Le problème n’est pas méthodologique mais organisationnel. 

Cela traduit souvent une absence d’arbitrage clair, un sponsor insuffisamment engagé ou une incapacité collective à renoncer. 

Dans ce contexte, MoSCoW ne révèle pas les priorités : elle met en lumière les dysfonctionnements de la gouvernance produit.

2) Associer la méthode MoSCoW au Story Mapping

L’exercice consiste à enrichir la Story Map en rangeant les différentes fonctionnalités dans des couloirs Must, Should, Could et Won’t :

L’ensemble des fonctionnalités du couloir Must (encadré rouge) constitue le PMV (Produit Minimum Viable). Rien ne peut être enlevé de cet ensemble pour une première mise en production de l’application.

Les couloirs Should, Could et Won’t peuvent faire l’objet de livraisons ultérieures si l’hypothèse de bénéfices associée au PMV est vérifiée, autrement dit si les objectifs et les résultats clefs associés au PMV sont atteints.

Dans le cas contraire, il sera préférable de pivoter ou bien d’arrêter le projet si aucun pivot n’est possible. 

Prioriser avec la méthode ROI

La priorisation macroscopique obtenue avec le Story Mapping et le MoSCoW est une première étape qui reste malgré tout insuffisante pour définir un ordre de priorité pour les fonctionnalités du backlog. 

Pour obtenir cet ordonnancement, nous vous proposons une première méthode simple basée sur le ROI.

1) Qu’est-ce que le ROI ?

Le ROI ou retour sur investissement (Return On Investment) est le ratio entre la valeur métier et la complexité.

Par conséquent, les fonctionnalités à forte valeur métier et faciles à implémenter ont un ROI élevé.

À l’inverse, les fonctionnalités à faible valeur métier et difficiles à implémenter ont un ROI faible.

Lorsque les fonctionnalités d’un projet agile sont priorisées par le ROI le plus fort, l’apport de valeur est important dès les premières itérations. 

En voici l’illustration à travers le graphique suivant :

L’apport de valeur est rapide dès les premières itérations. Les dernières itérations apportant peu de valeur, il peut être intéressant de se poser la question de ne pas les faire plutôt que de consommer la totalité de l’enveloppe budgétaire.

Le calcul du ROI donne une impression d’objectivité, mais il repose sur des estimations relatives et contextuelles.

Il convient donc de rester vigilant face à l’illusion de précision : un ROI chiffré ne remplace pas un arbitrage éclairé, il l’éclaire.

2) Déterminer la valeur métier avec un atelier « buy a feature »

L’objectif de l’atelier « buy a feature » est de faire collaborer de manière ludique les utilisateurs, les clients et les parties prenantes en les mettant en situation de contrainte budgétaire.

Chaque participant reçoit la même quantité d’argent fictif (exemple : billets de Monopoly) et doit acheter les fonctionnalités qu’il juge les plus importantes. Il peut discuter et négocier avec les autres participants.

La valeur métier est une valeur relative : une fonctionnalité qui se voit attribuer un billet de 500 est simplement 5 fois plus importante qu’une fonctionnalité qui se voit attribuer un billet de 100.

Un facilitateur encourage le débat en posant des questions : « Pourquoi cette fonctionnalité est-elle importante pour vous ? ».

À la fin du temps réglementaire, les fonctionnalités essentielles émergent.

Des points de friction apparaissent, ainsi que des fonctionnalités peu ou pas plébiscitées.

Au final, un classement est établi et constitue le meilleur compromis possible entre les acteurs.

La valeur métier étant maintenant connue, il reste à évaluer la complexité pour ensuite calculer le ROI.

3) Estimer rapidement les fonctionnalités du backlog

Pour avoir une idée de ce qui est simple ou complexe en termes de réalisation, il est essentiel d’embarquer vos développeurs.

Ils vont réaliser l’application et sont donc les plus légitimes pour estimer le travail à faire.

De manière logique, les estimations faites par les gens qui font le travail sont plus réalistes que celles effectuées à dire d’experts.

Le Product Owner explique aux développeurs les fonctionnalités une par une, dans l’ordre de la Story Map. 

Les développeurs les positionnent dans des couloirs de complexité qui suivent la suite de Fibonacci (1, 2, 3, 5, 8, 13, …). Il s’agit toujours d’une estimation relative.

Une complexité de 5 traduit une difficulté 5 fois plus importante qu’une complexité de 1. Notez que la complexité embarque le facteur temps.

Une fois les premières fonctionnalités positionnées, il est plus facile de positionner les suivantes en les comparant aux premières :

• « Cette nouvelle fonctionnalité à estimer est-elle de complexité plus forte, moins forte ou identique à ces autres fonctionnalités déjà estimées à 5 points ? »
• « La complexité est identique ». Elle est donc estimée à 5 points également
• « Cela semble plus facile ». Elle est alors comparée aux fonctionnalités estimées à 3 points
• « Cela semble plus difficile ». Elle est alors comparée aux fonctionnalités estimées à 8 points

Si l’équipe est nouvelle, il est possible que l’exercice soit périlleux.

Dans ce cas, insistez bien sur le fait que la démarche n’est pas engageante et que les estimations seront remises à jour régulièrement pour tenir compte du savoir-faire acquis itération après itération.

4) Établir une priorisation des fonctionnalités basée sur le ROI

La valeur métier et la complexité sont désormais connues pour toutes les fonctionnalités du backlog.

Il reste à calculer le ROI en divisant la valeur métier par la complexité, puis prioriser par le ROI.

Prioriser avec la méthode WSJF

Le calcul du ROI a l’avantage d’être simple mais il ne prend pas en compte la criticité temporelle, ni la réduction des risques, ni les leviers d’opportunités.

Nous vous proposons donc une méthode de priorisation plus élaborée, appelée WSJF.

1) Qu’est-ce que le WSJF ?

Le WSJF a été popularisé par SAFe (Scaled Agile Framework), un cadre méthodologique agile à grande échelle, qui permet de coordonner le travail de plusieurs équipes agiles pour des projets complexes.

Cette approche s’inspire des travaux de Don Reinertsen, pionnier du Lean Product Development.

Une méthode visant à concevoir des produits à forte valeur ajoutée en réduisant le gaspillage de temps, de ressources et de coûts, grâce à des cycles de développement rapides et à des ajustements continus.

L’auteur a démontré que, dans un environnement à forte incertitude, traiter en premier les tâches offrant le meilleur rapport entre valeur et effort permet d’accélérer le flux et d’optimiser l’investissement.

Le WSJF (Weighted Shortest Job First) qui signifie littéralement « travail qui apporte le plus de valeur le plus rapidement possible en premier » repose sur un calcul simple, mais puissant :

WSJF = Coût du délai / Taille du travail

• Le coût du retard regroupe l’impact financier, les opportunités manquées et les risques accrus, dans le cas où la livraison est retardée. 
• La taille du travail, quant à elle, désigne la durée ou l’effort nécessaire pour réaliser la fonctionnalité, incluant entre autres la maintenance prédictive.

Plus le WSJF est élevé, plus la tâche doit être traitée rapidement.

Cette priorisation factuelle permet aux équipes agiles de livrer rapidement ce qui apporte le plus de valeur, tout en gérant efficacement leurs ressources.

2) Deux exemples concrets pour mieux appréhender le WSJF

Voici deux exemples concrets pour mieux comprendre l’intérêt du WSJF.

Exemple 1 

3 machines agricoles dans des états d’avancement de construction différents possèdent un coût du retard identique, fixé à 2 $.

Autrement dit,  pour chaque machine, une pénalité de 2 $ est appliquée chaque jour, tant que la machine n’a pas été livrée.

Vous ne pouvez travailler que sur une machine à la fois.

Question : D’après vous, dans quel ordre est-il préférable de terminer ces machines pour minimiser les pénalités ?

Vous avez répondu « A puis B puis C » ? Bravo !

Pour s’en persuader, voici le graphe des pénalités en fonction du temps pour le scénario le plus favorable (A puis B puis C) et le plus défavorable (C puis B puis A) :

Le scénario le plus défavorable génère une pénalité totale de 74 $ alors que le scénario le plus favorable génère une pénalité totale de 38 $. 

Appliquons maintenant la formule du WSJF à notre exemple :

• WSJF (A) = 2 / 1 = 2 
• WSJF (B) = 2 / 3 = 0.66
• WSJF (C) = 2 / 10 = 0.2

La priorisation par le WSJF le plus élevé (A puis B puis C) conduit bien au scénario le moins pénalisant.

Exemple 2

3 machines agricoles au même état d’avancement de construction possèdent une taille de travail identique mais des coûts du retard différents (3 $ pour A, 2 $ pour B, 1 $ pour C).

Question : D’après vous, dans quel ordre est-il préférable de terminer ces machines pour minimiser les pénalités ?

Vous avez répondu « A puis B puis C » ? Bravo !

En traçant le graphe des pénalités en fonction du temps, vous ferez le constat que le scénario le plus défavorable génère une pénalité totale de 42 $ alors que le scénario le plus favorable génère une pénalité totale de 30 $. 

Appliquons maintenant la formule du WSJF à notre exemple :

• WSJF (A) = 3 / 3 = 1 
• WSJF (B) = 2 / 3 = 0.66
• WSJF (C) = 1 / 3 = 0.33

La priorisation par le WSJF le plus élevé (A puis B puis C) conduit bien au scénario le moins pénalisant.

3) Comprendre les critères du WSJF

Le WSJF est calculé à partir de 4 critères :

• Valeur métier
• Criticité temporelle
• Réduction des risques ou opportunités
• Taille du travail

Voici, pour chaque critère, la définition et les bonnes questions à se poser pour le valoriser :

4) Établir une priorisation des fonctionnalités basée sur le WSJF

Il est important de procéder critère par critère. 

Imaginons que nous commencions par le critère « valeur métier » :

• Étape 1 : nous recherchons la fonctionnalité de plus faible valeur métier et nous lui attribuons une valeur métier égale à « 1 »
• Étape 2 : la valeur métier de toutes les autres fonctionnalités est estimée par rapport à ce « 1 » en utilisant les valeurs de la suite de Fibonacci (1, 2, 3, 5, 8, 13, 20, …)

Chaque critère doit comporter au moins un « 1 ». Cela permet d’accorder la même importance à chaque critère.

La démarche est à répéter pour l’ensemble des critères du WSJF.

Voici un exemple de calcul du WSJF pour un site de e-commerce dédié aux livres : 

Dans cet exemple, la fonctionnalité « Évaluation de livres » est prioritaire. Malgré un coût du délai faible, son WSJF est élevé parce qu’elle est rapide à implémenter.

Prioriser avec la méthode RICE

Bien que le calcul du RICE pour chaque fonctionnalité du backlog nécessite plus de temps que le calcul du WSJF, cette alternative a le mérite de générer des discussions qui permettent d’aligner l’ensemble des acteurs sur les enjeux liés à chaque fonctionnalité.

1) Qu’est-ce que le RICE ?

RICE est un acronyme qui fait référence à 4 critères utilisés pour prioriser : 

• R pour Reach (la portée), 
• I pour Impact, 
• C pour Confidence (la confiance), et 
• E pour Effort.

Les fonctionnalités du backlog sont priorisées selon leur RICE.

2) Comprendre les critères du RICE

Voici, pour chaque critère, la définition et les bonnes questions à se poser pour le valoriser :

3) Établir une priorisation des fonctionnalités basée sur le RICE

Comme pour le WSJF, il est important de procéder critère par critère.

L’horizon de temps choisi pour valoriser le critère Reach (Portée) doit être le même pour l’ensemble des fonctionnalités.

Reprenons notre exemple de site de e-commerce dédié aux livres.

Parmi nos 5 000 utilisateurs qui se connectent chaque mois :

• 90 % d’entre eux ont exprimé le besoin de gérer leurs profils et l’impact est fort car nous sommes confiants à 80 % sur le fait que les données des utilisateurs nous seront très utiles pour nos futures campagnes publicitaires.
• 40 % d’entre eux ont exprimé le besoin d’ajouter des commentaires. Nous pensons que l’impact est faible. Certains utilisateurs avouent ne pas prendre le temps de lire les commentaires mais nous avons peu de statistiques sur le sujet. Notre niveau de confiance est à 40 %.
• 20 % d’entre eux ont exprimé le besoin d’évaluer les livres. Les utilisateurs admettent qu’une évaluation permettrait de les rassurer avant de se décider à acheter. Nous sommes confiants à 60 % sur le fait que cette fonctionnalité pourrait avoir un impact fort sur nos ventes.

Dans cet exemple, la fonctionnalité « Gestion du profil » est prioritaire parce qu’elle impacte fortement une large majorité d’utilisateurs.

Il est intéressant de noter que pour un même contexte, la priorisation par le WSJF et le RICE donnent des résultats différents.

D’où l’importance de maîtriser plusieurs méthodes pour prendre des décisions éclairées.

Conclusion

Aujourd’hui, nos contextes business sont en perpétuelle évolution, empreints d’incertitudes et font face à une concurrence accrue. Par conséquent, les priorités d’hier sont rarement celles de demain.

La priorisation en agile n’est donc pas un acte ponctuel réalisé en début de projet. Mais plutôt un exercice récurrent qui permet d’intégrer les nouveaux apprentissages, les retours du marché et les opportunités émergentes.

Chaque atelier de priorisation est une occasion de réaligner les équipes sur la valeur réelle à produire, au bon moment.

En cultivant cette discipline, les organisations renforcent leur capacité d’adaptation et leur résilience.

La priorisation devient alors un levier stratégique, au service de la création de valeur continue.