Il y a quelques mois, j'ai assisté à une session de PI planning où une équipe de douze personnes a débattu pendant quarante minutes pour savoir si un bouton "voir les alternatives produit" était plus important qu'un bouton "notify me" sur les articles en rupture. Les deux PMs avaient des slides. Les deux avaient des données. Les deux étaient convaincus. La discussion s'est finie comme ce genre de discussion se finit toujours; la personne qui parlait le plus fort a gagné, et les autres sont retournés à leur laptop avec une rancune silencieuse.
Cette réunion est la raison pour laquelle j'ai reconstruit notre Calculateur WSJF. Pas parce que le monde avait besoin d'un énième outil de priorisation de backlog, mais parce que j'en avais assez de voir des équipes intelligentes jeter un trimestre entier à débattre de ressentis quand les maths existent depuis les années 80.
Le truc qu'on ne vous dit pas sur la priorisation
La plupart des gens pensent que prioriser, c'est choisir ce qui a le plus de valeur. Non. C'est choisir ce où valeur divisée par taille est le plus élevé. Cette distinction semble pédante jusqu'à ce que vous réalisiez que c'est la différence entre livrer huit petites victoires dans un trimestre ou livrer une seule "initiative stratégique" lourdingue que personne ne voulait vraiment.
C'est toute la thèse de Weighted Shortest Job First. Vous notez chaque item du backlog sur deux choses; combien ça coûte de retarder, et quelle est la taille du travail. Puis vous divisez. Le plus gros score gagne. C'est tout. Pas de débat sur les story points à 9h un lundi, pas de "est-ce que la page de login est un 3 ou un 5", pas de comédie où votre intuition deviendrait une méthodologie.
WSJF = Coût du Retard / Taille du Travail
Don Reinertsen a popularisé ça dans The Principles of Product Development Flow, que j'appellerais le meilleur livre d'agile jamais écrit si l'expression "livre d'agile" ne poussait pas la plupart des ingénieurs à regarder la fenêtre la plus proche. En vrai, c'est un livre de théorie des files d'attente déguisé en livre de management, et c'est précisément pourquoi il est si bon.
Le Coût du Retard, c'est trois choses, pas une
C'est là que la plupart des tableurs WSJF se trompent. Le Coût du Retard n'est pas un seul chiffre. C'est la somme de trois questions très différentes:
- Valeur Métier. Si on livrait ça demain, à quel point les utilisateurs ou le business s'en soucieraient ? Revenus, rétention, un OKR concret. Concret quand vous pouvez, relatif sinon.
- Criticité Temporelle. La valeur se dégrade-t-elle avec le temps ? Une feature Black Friday livrée en décembre vaut à peu près zéro. Une date de conformité réglementaire ratée vaut moins que zéro.
- Réduction de Risque / Ouverture d'Opportunité. Est-ce que ça débloque autre chose, ou enlève de l'incertitude ? Le travail d'infrastructure ennuyeux vit ici, et c'est en général là qu'il se fait enterrer.
Additionnez les trois. Voilà le Coût du Retard. Divisez par la Taille du Travail. Voilà WSJF. La raison pour laquelle ça marche, ce n'est pas que les chiffres sont précis; c'est que la conversation devient précise. Vous ne pouvez plus prétendre qu'un spike de réduction de risque est une feature de revenu. Chaque item doit se justifier sur trois axes avant d'avoir un score.
Pourquoi l'estimation relative bat les heures à tous les coups
L'autre piège, c'est le dimensionnement. Les gens veulent estimer en jours. Ne le faites pas. Les humains sont terribles pour estimer des durées, et des décennies de recherche comportementale le confirment; la loi de Parkinson à elle seule devrait vous suffire. Ce que les humains font correctement, c'est comparer deux choses et dire "celui-là est plus gros".
Donc notez en Fibonacci (1, 2, 3, 5, 8, 13, 20) ou en tailles de t-shirt (XS, S, M, L, XL, XXL). Les écarts comptent; passer de 5 à 8 force une conversation que "4 jours vs 5 jours" ne force pas. Notre outil supporte les deux parce que les équipes se disputent sur ça, et la dispute ne vaut pas le coup. Choisissez-en une. Avancez.
Ce que l'outil fait vraiment
Le Calculateur WSJF tourne dans votre navigateur. Rien ne quitte votre machine. Je suis obsessif là-dessus pour les outils de product management en particulier; votre roadmap est précisément le genre de chose que vous ne voulez pas laisser sur le serveur de quelqu'un d'autre.
Voici ce qu'on a intégré après avoir vu des équipes l'utiliser:
- Templates pour domaines courants. E-commerce, SaaS, plateforme interne, secteur régulé. Démarrez depuis quelque chose qui a déjà du sens.
- Analyse What-if. Gonflez la taille du top 1 de 25%. L'ordre change-t-il ? Si oui, votre priorité numéro un est fragile; réestimez avant de vous engager.
- Indicateur de robustesse. Si les trois meilleurs scores WSJF sont à moins de 10% l'un de l'autre, traitez-les comme équivalents et laissez la capacité d'équipe décider. L'outil le montre en temps réel, vous arrêtez donc de prétendre qu'un 4,20 est vraiment plus gros qu'un 4,10.
- Liens partageables. Copiez une URL, collez-la dans les notes du PI planning, tout le monde charge le même état du backlog. Pas d'exports Jira, pas de CSV qui traînent dans Slack.
- Export CSV et PDF. Parce que certains stakeholders ne font confiance qu'à un PDF.
Quand WSJF est la mauvaise réponse
Je vais vous épargner une erreur que j'ai faite. WSJF n'est pas un framework universel de priorisation. C'est le bon outil quand:
- Vous avez 15 items de backlog ou plus, grosso modo comparables.
- Votre équipe fait de la livraison continue avec des cycles courts.
- Le coût du retard varie vraiment d'un item à l'autre (certains sont sensibles au temps, d'autres non).
C'est le mauvais outil quand:
- Vous avez un seul pari stratégique et trois tickets de support. Faites le pari stratégique.
- Tout est aussi urgent. Alors rien ne l'est, et vous avez un problème de management, pas de priorisation.
- Vous essayez de choisir entre deux produits. C'est une question Kano ou portfolio.
Pour les décisions binaires dedans/dehors, partez sur MoSCoW ou la matrice d'Eisenhower. Pour du ranking de features grand public avec une formule plus simple, RICE est plus accessible. J'ai construit les trois; chacun résout une forme légèrement différente du problème.
Le rituel de réunion qui marche vraiment
WSJF se casse quand ça devient un rituel. Le calculateur fait les maths; les humains doivent faire la discussion. Voici la boucle que j'ai vue marcher:
- Notez d'abord le Coût du Retard, ensemble. Utilisez le planning poker pour faire remonter les désaccords. Si deux personnes ont noté 3 et 13, c'est intéressant; creusez.
- Notez la Taille du Travail en dernier. Si vous connaissez la taille d'abord, elle ancre l'estimation de valeur. Les humains sont paresseux comme ça.
- Lisez le top 3 à voix haute. Si quelqu'un grimace, renotez.
- Verrouillez et livrez. Ne renotez pas en milieu de sprint. Tout l'intérêt, c'est que le vous d'hier et le vous d'aujourd'hui aviez des intuitions différentes mais que les maths n'ont pas bougé.
Pour les engagements à plus long terme, mariez WSJF avec du forecasting probabiliste. J'ai écrit un papier entier sur le forecasting Monte Carlo pour la livraison agile qui se marie très bien; un outil vous dit quoi faire ensuite, l'autre vous dit quand vous aurez vraiment fini.
Ce qui m'a surpris
Quand j'ai livré le calculateur, je m'attendais à ce que les ingénieurs l'utilisent. Il s'est avéré que les product managers sont les plus gros utilisateurs, et ce qu'ils préfèrent, ce n'est pas le score. C'est la piste d'audit. Chaque classement montre les trois sous-scores; quand un stakeholder demande "pourquoi ma feature n'est pas en haut ?", le PM pointe un nombre et dit "parce que ta Criticité Temporelle est S et ta Taille de Travail est XL". La discussion se termine en une minute, pas en une semaine.
C'est ça le vrai sens de tout outil de priorisation. Pas remplacer le jugement. Rendre le jugement visible au point que la personne la plus bruyante ne puisse plus écraser les autres.
Essayez-le ici: kitmul.com/fr/agile-project-management/wsjf-calculator. C'est gratuit, ça tourne dans votre navigateur, et votre backlog vous appartient toujours.