Dans un projet classique, la liste des tâches arrive souvent déjà ordonnée par le commanditaire, et le chef de projet exécute selon un plan préétabli. En contexte agile, cette logique ne tient plus: le backlog (liste ordonnée des travaux à réaliser) évolue à chaque itération, et la question “que fait-on en premier?” revient à chaque sprint (itération de durée fixe, généralement une à quatre semaines).
Cette répétition n’est pas un défaut du modèle, c’est le mécanisme qui permet d’ajuster le tir en continu, à condition de disposer de critères de priorisation solides.
Quand tout est prioritaire, rien ne l’est
Le premier piège de la priorisation agile est le refus de choisir. Les parties prenantes ont tendance à classer chaque besoin comme urgent et indispensable. Le résultat est un backlog où tout se retrouve au même niveau, ce qui revient à ne rien prioriser du tout.
Forcer un classement est une discipline managériale avant d’être un exercice technique. Le Product Owner (rôle Scrum responsable de maximiser la valeur du produit en ordonnant le backlog) porte cette responsabilité, mais il ne peut pas l’exercer seul. Il a besoin de critères explicites et partagés pour justifier ses choix devant l’équipe et les parties prenantes.
Quatre critères fondamentaux reviennent dans la plupart des cadres de priorisation, comme le rappelle le praticien Roman Pichler: la valeur business, le risque, la facilité de livraison et les dépendances techniques.
MoSCoW: catégoriser pour clarifier
La méthode MoSCoW classe les exigences en quatre catégories: Must have (indispensable), Should have (important), Could have (souhaitable) et Won’t have (exclu pour cette itération). Largement utilisée dans PRINCE2 et AgilePM, elle a l’avantage d’être compréhensible par des parties prenantes non techniques.
Son fonctionnement est simple: chaque élément du backlog est placé dans l’une des quatre catégories par discussion collective. Les “Must” entrent dans le sprint en cours, les “Should” complètent si la capacité le permet, les “Could” attendent, les “Won’t” sont explicitement reportés.
La limite principale de MoSCoW est la dérive de la catégorie “Must”. Sans discipline, cette catégorie gonfle jusqu’à contenir la majorité du backlog, ce qui annule l’intérêt du classement. Une règle empirique consiste à plafonner les “Must” à 60% de la capacité du sprint pour laisser une marge aux imprévus et aux éléments “Should” à forte valeur.
Matrice valeur/effort: visualiser les arbitrages
La matrice valeur/effort est un outil visuel à deux axes: la valeur business estimée en ordonnée, l’effort de réalisation en abscisse. Chaque élément du backlog est positionné dans l’un des quatre quadrants.
Les éléments à haute valeur et faible effort, parfois appelés “gains rapides”, constituent le choix évident pour les prochaines itérations. À l’opposé, les éléments coûteux à faible valeur sont des candidats à l’élimination. Les deux autres quadrants exigent un arbitrage plus fin: les gros projets à forte valeur méritent d’être planifiés sur plusieurs sprints, tandis que les petites tâches à faible valeur peuvent être traitées en fin de sprint si la capacité le permet.
L’outil fonctionne bien pour un backlog de taille moyenne, mais ses estimations restent subjectives. La valeur perçue d’un élément varie selon l’interlocuteur, et l’effort est souvent sous-estimé. Pour limiter ces biais, le positionnement doit se faire en groupe, avec l’équipe de réalisation présente pour calibrer l’axe de l’effort.
WSJF: quand le coût du retard compte
Le WSJF (Weighted Shortest Job First, priorisation par le travail le plus court pondéré) apporte une rigueur supplémentaire. Sa formule est directe: le coût du délai (valeur économique perdue chaque semaine où un élément n’est pas livré) divisé par la durée estimée du travail. Développé dans le cadre SAFe, il favorise les éléments à fort impact qui peuvent être livrés rapidement.
Le coût du délai combine trois composantes: la valeur business intrinsèque, l’urgence temporelle (une fonctionnalité liée à une échéance réglementaire perd toute valeur après la date limite) et la réduction de risque ou d’opportunité.
Le WSJF convient particulièrement aux environnements où les contraintes de temps sont fortes et les éléments du backlog nombreux. Son inconvénient est qu’il exige un calibrage collectif rigoureux: si les estimations de coût du délai sont fantaisistes, le classement qui en résulte l’est aussi. En pratique, l’équipe attribue des valeurs relatives (sur une échelle de Fibonacci, par exemple) plutôt que des montants absolus, ce qui réduit les débats sans éliminer la subjectivité.
Les dépendances, contrainte invisible
Aucune méthode de priorisation ne fonctionne en vase clos. Un élément classé “Must” ou positionné en haut du WSJF peut être impossible à livrer si ses dépendances techniques ne sont pas satisfaites. La priorisation doit donc tenir compte de l’ordre de livraison faisable, pas seulement de l’ordre souhaitable.
En pratique, cela signifie que le Product Owner et l’équipe technique doivent croiser leurs classements. Le Product Owner apporte la perspective de valeur, l’équipe apporte les contraintes d’architecture et de séquencement. Ignorer cette étape produit des sprints où l’équipe passe plus de temps à débloquer des prérequis qu’à livrer de la valeur.
Quelle méthode choisir?
Le choix dépend du contexte plus que de la supériorité intrinsèque d’un outil. MoSCoW fonctionne bien en début de projet, quand le périmètre est encore large et que l’objectif principal est de séparer l’essentiel du superflu. La matrice valeur/effort convient aux sessions de refinement régulières avec un backlog stabilisé. Le WSJF s’impose quand les enjeux économiques du séquencement deviennent significatifs, typiquement sur des programmes de grande envergure.
Ces outils ne sont pas exclusifs. Un Product Owner peut utiliser MoSCoW pour le cadrage initial, puis affiner avec une matrice valeur/effort à chaque sprint, et réserver le WSJF aux arbitrages stratégiques entre épics concurrentes. L’important n’est pas la sophistication de la méthode, mais la transparence des critères: une priorisation comprise et acceptée par l’équipe vaut mieux qu’un calcul élaboré que personne ne peut reproduire.
Prioriser le risque, pas seulement la valeur
Un critère souvent négligé mérite d’être intégré à toute méthode de priorisation: le risque. Placer les éléments incertains en début de sprint permet de valider ou d’invalider rapidement des hypothèses, avant que les alternatives ne se referment. Cette approche, cohérente avec le principe agile de “fail fast”, transforme la priorisation en outil de gestion des risques.
Le modèle de Kano (classification des fonctionnalités selon leur impact sur la satisfaction) offre un éclairage complémentaire en distinguant les fonctionnalités de base, dont l’absence provoque une insatisfaction immédiate, des fonctionnalités de performance, dont la présence améliore la satisfaction de façon linéaire, et des fonctionnalités d’attractivité, qui surprennent positivement. Consacrer un sprint entier à améliorer une fonctionnalité de performance alors qu’une fonctionnalité de base manque encore est un classique de la mauvaise priorisation.