Décoder le WSJF : Un guide pratique pour le calcul du Weighted Shortest Job First

Le casse-tête de la priorisation : Au-delà de l’intuition

Dans le développement de produits complexes, décider de ce qu’il faut construire ensuite est souvent un défi majeur. Avec des ressources limitées, des délais serrés et des exigences concurrentes des parties prenantes, comment déterminer objectivement quelles fonctionnalités ou initiatives apporteront le plus de valeur, le plus rapidement possible ? S’en remettre à l’intuition ou à la voix la plus forte conduit souvent à des résultats sous-optimaux. C’est là qu’intervient le Weighted Shortest Job First (WSJF).

Le WSJF est un modèle de priorisation puissant, largement reconnu et utilisé, en particulier au sein du Scaled Agile Framework (SAFe). Il fournit un cadre économique pour la prise de décision, déplaçant l’attention des opinions subjectives vers des calculs objectifs basés sur le coût du délai (Cost of Delay) potentiel de la livraison de valeur par rapport à l’effort requis.

Cet article servira de guide pratique, décomposant les éléments du WSJF et expliquant comment le calculer, afin que vous puissiez commencer à exploiter sa puissance pour une priorisation plus efficace.

Pourquoi prioriser sur des bases économiques ? Comprendre le Cost of Delay (CoD)

Le différenciateur fondamental du WSJF est l’importance qu’il accorde au Cost of Delay (CoD). Au lieu de se demander simplement “Quelle est la valeur de cette fonctionnalité ?”, le CoD pose la question suivante : “Quel est l’impact économique si nous retardons la livraison de cette fonctionnalité ?” Cet impact ne se limite pas à une perte potentielle de revenus ; il inclut des facteurs tels que :

Les opportunités de marché manquées
L’incapacité à répondre aux menaces concurrentielles
Les risques commerciaux ou techniques continus qui ne sont pas atténués
La perte de satisfaction client ou l’attrition (churn) potentielle

Raisonner en termes de CoD impose un changement crucial : prioriser en fonction de la valeur dans le temps et de l’urgence, et non plus seulement sur des estimations de valeur statiques.

Décomposer les éléments du Cost of Delay (CoD)

Le Cost of Delay n’est généralement pas une valeur monétaire unique estimée directement. Il est plutôt calculé en estimant plusieurs facteurs contributifs par rapport aux autres éléments du backlog. Les composantes standards utilisées dans SAFe sont :

Valeur Utilisateur-Business (User-Business Value) — Quelle valeur relative cela apporte-t-il au client ou à l’entreprise ? Cela permet-il d’augmenter les revenus, d’améliorer la part de marché, de renforcer la satisfaction client ou de soutenir les objectifs stratégiques ?
Criticité Temporelle (Time Criticality) — Quelle est l’urgence ? La valeur diminue-t-elle rapidement avec le temps ? Y a-t-il une échéance fixe ou une fenêtre de marché spécifique à atteindre ? Les utilisateurs risquent-ils de partir si cela n’est pas disponible rapidement ?
Réduction des Risques / Création d’Opportunités (RR/OE Value) — Cette fonctionnalité réduit-elle des risques commerciaux ou techniques importants (par exemple, des failles de sécurité, des pannes potentielles) ? Ouvre-t-elle de nouvelles opportunités commerciales ou permet-elle des innovations futures ?

Il est crucial de noter que ces composantes sont estimées de manière relative par rapport à d’autres fonctionnalités ou Epics. Une technique courante consiste à utiliser une suite de Fibonacci modifiée (1, 2, 3, 5, 8, 13, 20…). Vous comparez les éléments : La Fonctionnalité A a-t-elle environ deux fois plus de valeur que la Fonctionnalité B ? La Fonctionnalité C est-elle nettement plus critique sur le plan temporel que la Fonctionnalité A ? La somme de ces estimations relatives vous donne le Cost of Delay relatif total = Valeur Utilisateur-Business + Criticité Temporelle + Valeur RR/OE.

L’autre côté de l’équation : La taille de la tâche (Job Size)

Le dénominateur dans le calcul du WSJF est la Taille de la tâche (Job Size) (parfois appelée Durée de la tâche). Cela représente l’effort ou le temps relatif requis pour accomplir le travail. Les unités d’estimation courantes incluent les Story Points ou les “semaines d’équipe” normalisées.

Pourquoi diviser par la Job Size ? Parce que le WSJF vise à maximiser les avantages économiques rapidement. Un élément de grande valeur qui prend beaucoup de temps pourrait offrir un avantage économique global par unité de temps inférieur à celui d’un élément de valeur légèrement moindre mais qui peut être achevé beaucoup plus vite. Nous voulons prioriser les tâches les plus “courtes” (par rapport à leur CoD) pour permettre un flux de valeur et des retours plus rapides. Tout comme les composantes du CoD, la Job Size doit également être estimée de manière relative par rapport aux autres éléments.

Calculer le WSJF : Assembler les pièces du puzzle

Avec les estimations du Cost of Delay et de la Job Size, le calcul du WSJF est simple :

WSJF = Cost of Delay / Job Size

(Où Cost of Delay = Valeur Utilisateur-Business + Criticité Temporelle + Valeur RR/OE)

Les éléments ayant un score WSJF plus élevé sont priorisés en premier.

Regardons un exemple simple

Fonctionnalité	Valeur Utilisateur-Business	Criticité Temporelle	Valeur RR/OE	Cost of Delay (CoD)	Job Size	WSJF (CoD / Job Size)
Fonctionnalité A	8	5	3	16	5	3.2
Fonctionnalité B	13	1	1	15	3	5.0
Fonctionnalité C	5	8	5	18	8	2.25

Analyse

La Fonctionnalité C a le Cost of Delay total le plus élevé (18).
Cependant, la Fonctionnalité B a le score WSJF le plus élevé (5.0) car son CoD relativement élevé (15) est associé à une petite Job Size (3). Elle délivre une valeur significative rapidement.
La Fonctionnalité A vient ensuite (WSJF 3.2).
La Fonctionnalité C, malgré son CoD élevé, arrive en dernier en raison de sa grande Job Size (WSJF 2.25).

Sur la base du WSJF, l’ordre de priorisation serait : 1. Fonctionnalité B, 2. Fonctionnalité A, 3. Fonctionnalité C.

Les défis pratiques de la mise en œuvre du WSJF

Bien que le concept et le calcul soient clairs, l’application cohérente du WSJF dans la pratique présente des défis :

Cohérence des estimations : S’assurer que tout le monde estime les composantes du CoD et la Job Size de manière relative et cohérente entre les différentes équipes et éléments nécessite de la pratique et de la facilitation.
Surcharge de calcul : Calculer manuellement le WSJF pour des dizaines ou des centaines d’éléments du backlog, et recalculer à chaque fois que les estimations changent, est chronophage et source d’erreurs.
Visibilité et tri : Rendre les scores WSJF facilement visibles et triables dans l’outil de flux de travail principal de l’équipe (comme Jira) est crucial pour une utilisation efficace. Les scores statiques dans des feuilles de calcul externes deviennent rapidement obsolètes ou sont ignorés.
Intégration des outils : Sans une intégration adéquate, le suivi des valeurs des composantes sous-jacentes et du score WSJF résultant directement sur l’élément de travail peut s’avérer fastidieux.

Relever ces défis nécessite des accords d’équipe clairs sur les pratiques d’estimation, mais souligne également le besoin d’outils intégrés. Des plateformes comme Jira, lorsqu’elles sont enrichies de capacités spécialisées ou de plugins, peuvent automatiser les calculs du WSJF en fonction des champs des composantes et offrir un tri dynamique, réduisant considérablement la charge de travail et faisant du WSJF un mécanisme de priorisation pratique et vivant.

Conclusion : Priorisez plus intelligemment avec le WSJF

Le Weighted Shortest Job First offre une approche de priorisation robuste et axée sur l’économie qui aide les équipes à se concentrer sur la maximisation de la vitesse de livraison de la valeur. En comprenant le Cost of Delay et en le comparant à la Job Size, vous pouvez dépasser les débats subjectifs pour aller vers une prise de décision objective et transparente. Bien que sa mise en œuvre pratique exige de la discipline, l’adoption du WSJF – soutenue par les processus et les outils adéquats – donne aux équipes les moyens d’optimiser le flux et de livrer de manière cohérente ce qui compte vraiment le plus pour l’entreprise.