Cadre Agile WSJF

Le Weighted Shortest Job First (WSJF) vous aide à prioriser le travail en équilibrant le coût du délai par rapport à la taille de la tâche. Ce cadre offre une valeur maximale avec des ressources limitées dans des environnements en évolution rapide.

La priorisation WSJF en bref

Créez un compte Ducalis gratuit

Calcul WSJF

Score WSJF = (Valeur métier + Criticité temporelle + Réduction des risques) / Taille de la tâche

Critères

Valeur utilisateur/métier classe les tâches selon leur importance pour les utilisateurs et leur impact potentiel sur les revenus.

Criticité temporelle classe les tâches selon l'urgence — comment la valeur se dégrade avec le temps ou combien de clients vous pourriez perdre en retardant.

Réduction des risques et création d'opportunités met en évidence les tâches qui peuvent ne pas générer de revenus immédiats mais bénéficient aux résultats à long terme. Certaines solutions éliminent les risques techniques ou juridiques et permettent des économies ultérieures.

Durée de la tâche (également appelée story points, points de fonctionnalité, effort ou taille relative) mesure la complexité de mise en œuvre. Avec cette estimation, les petits nombres sont préférables.

Évaluation

1. Évaluez chaque critère sur l'échelle de Fibonacci : 1 (aucun impact), 2, 3, 5, 8, 13, 21 (impact maximal).

2. Organisez des sessions de priorisation collaborative avec des équipes de cinq à onze personnes.

3. Évaluez les tâches avant chaque événement de planification d'itération (Sprint).

4. Normalisez les différents scores par la discussion avec les coéquipiers.

5. Divisez les initiatives avec des tailles de tâche de '21' et '13' en projets plus petits (raffinement du Backlog).

6. Réinitialisez les scores d'évaluation toutes les cinq itérations (Program Increment) pour refléter l'environnement en évolution rapide.

Appliquez le modèle de priorisation Ducalis prêt à l'emploi

Pas besoin de personnaliser les critères, les formules et les échelles. Utilisez-les comme modèle de base pour lancer la réunion.

Note

WSJF n'est pas qu'une formule — c'est une partie d'un cadre de flux de travail complet pour les entreprises. La magie se produit lorsque vous changez votre approche de prise de décision : organisez des sessions de priorisation collaborative, définissez l'expiration des scores, spécifiez les critères et expliquez les descriptions des tâches aux coéquipiers. Cet article fournit des outils pour créer cette habitude de priorisation et changer votre état d'esprit.

Définition de WSJF

WSJF signifie Weighted Shortest Job First — un cadre de priorisation pour prioriser les backlogs en calculant le coût du délai (CoD) relatif et la taille de la tâche (un indicateur de durée). Le CoD se calcule comme une somme : Valeur utilisateur/métier + Réduction des risques et création d'opportunités + Criticité temporelle. Il fait partie de la méthodologie SAFe.

Les priorités du Backlog sont continuellement mises à jour en fonction des scores de priorité WSJF. Le cadre ignore commodément et automatiquement les coûts irrécupérables, un principe fondamental de l'économie Lean.

Dans un système basé sur les flux, la priorisation continue des tâches pour mettre à jour les priorités fournit les meilleurs résultats économiques pour :

• Le séquençage des tâches en poussant les gains rapides vers l'avant
• L'équilibre du résultat financier le plus élevé tout en réduisant les ressources investies
• La mise à jour régulière du CoD et des tailles de tâche pour refléter l'environnement en évolution rapide

Qu'est-ce que SAFe ?

Le Scaled Agile Framework (SAFe), selon ScaledAgile.com, est un système de mise en œuvre des pratiques Agile, Lean et DevOps à grande échelle. Il prend les meilleures idées de la livraison de produits agiles et les étend à toute l'entreprise pour fournir l'agilité métier. SAFe est le cadre le plus populaire pour les grandes entreprises car il fonctionne : il est fiable, personnalisable et durable.

Il est constamment mis à jour et comporte des versions. En 2022, la dernière version est la 5.1, et SAFe couvre sept domaines principaux de l'entreprise :

• Agilité d'équipe et technique
• Livraison de produits agiles
• Livraison de solutions d'entreprise
• Gestion de portefeuille Lean
• Agilité organisationnelle
• Culture d'apprentissage continu
• Leadership Lean-Agile

Résultats promis :

• +50 % de réduction du délai de mise sur le marché
• +50 % de réduction des défauts
• +35 % d'augmentation de la productivité
• +30 % d'employés plus heureux et plus engagés

Dans cet article, nous nous concentrerons sur la base — le cadre de prise de décision WSJF.

Téléchargez le modèle WSJF gratuit :

Comment calculer WSJF

Formule WSJF

Le cadre Weighted Shortest Job First (WSJF) vous aide à décider quelle tâche choisir ensuite pour offrir le plus de valeur avec des ressources limitées en trouvant un équilibre entre le coût du délai (CoD) et la taille de la tâche dans un monde en évolution rapide.

Calculer le score WSJF

Score WSJF = Coût du délai / Taille de la tâche

Calculez le CoD, qui définit trois types de problèmes de développement de produits à surveiller.

Coût du délai = Valeur utilisateur-métier + Criticité temporelle + Réduction des risques | Valeur de création d'opportunités

Évaluez chaque critère avec une échelle de 1, 2, 3, 5, 8, 13, 21.

Principes d'estimation :

• L'estimation WSJF vise à comprendre le niveau d'incertitude, pas à calculer les heures ou l'argent (ce qui est presque impossible). C'est pourquoi nous estimons la probabilité plutôt que le temps exact pour accomplir une tâche particulière. C'est ce qu'on appelle l'évaluation relative.

• Comme l'objectif principal est de fournir de la valeur à chaque itération, la médiane de la séquence sera « une itération ».

• Une itération = deux semaines. Notre base de planification. Nous calculons les nombres de story points pour une itération de deux semaines.

• Program Increment (PI) = cinq itérations (dix semaines). Selon SAFe, le PI est une période pendant laquelle un Agile Release Train (ART) fournit une valeur incrémentale sous forme de logiciels et de systèmes fonctionnels et testés. Toute l'équipe réalise quelque chose d'important pour le produit. En d'autres termes, l'organisation publie une grande mise à jour, après quoi elle doit réévaluer son Backlog, réfléchir et discuter à nouveau des priorités.

Personnalisation

Ce n'est qu'une recommandation, et vous êtes libre de personnaliser l'approche de toute manière confortable pour votre équipe. Plus loin dans cet article, nous verrons comment mieux comprendre et personnaliser les critères précisément pour vos besoins métier.

Valeur utilisateur-métier (UBV)

Nouvelles fonctionnalités et innovations qui font progresser votre produit. Par exemple, les options de connexion de sécurité d'entreprise aident à éviter les plaintes de gros clients, ce qui conduit à des ventes.

La valeur utilisateur/métier (UBV) classe vos tâches selon leur importance relative pour l'utilisateur (priorisation de la désirabilité) et leur impact potentiel sur les revenus (priorisation financière). À ce stade, vous estimez l'efficacité de cette solution pour promouvoir votre métrique North Star. Comme de nombreux facteurs peuvent influencer l'UBV, commencez à réfléchir à l'impact métier et augmentez votre confiance que tout fonctionnera.

Questions à répondre : Quelle métrique produit vitale pouvez-vous mettre à jour ? Quelle est l'importance pour les utilisateurs ? Quel est l'impact sur les revenus ?

Évaluation de la valeur utilisateur-métier avec la séquence de Fibonacci

• 1 point : aucune valeur utilisateur-métier du tout ; cette tâche est liée à autre chose
• 2 points : l'impact métier et la confiance les plus bas
• 3 points : faible impact métier et confiance
• 5 points : impact métier modéré, confiance modérée
• 8 points : impact métier et confiance élevés
• 13 points : impact métier et confiance très élevés
• 21 points : l'impact métier et la confiance les plus élevés

Criticité temporelle (TC)

Évaluez l'urgence. Les initiatives ont des échéances justifiées comme les nouvelles réglementations, les déclarations fiscales, les promotions saisonnières, etc.

La criticité temporelle classe les tâches selon l'urgence. Vous estimez comment la valeur se dégradera avec le temps ou combien de clients vous pourriez perdre si vous tardez.

Notre calendrier d'estimation va d'une itération (deux semaines) à un Program Increment (PI) (dix semaines). À chaque cycle de PI, nous organisons une nouvelle session de réévaluation (après l'expiration des scores) et décidons comment l'urgence a changé.

Questions à répondre : Quelle est l'urgence pour l'entreprise ? Les utilisateurs attendront-ils ou passeront-ils à une autre solution ? Y a-t-il une échéance fixe ?

Évaluation de la criticité temporelle avec la séquence de Fibonacci

• 1 point : pas du tout une tâche urgente
• 2 points : peut attendre jusqu'au prochain cycle d'estimation (après l'expiration des scores toutes les cinq itérations)
• 3 points : peut attendre quatre Sprints (environ huit semaines)
• 5 points : urgence modérée, peut attendre trois Sprints (environ six semaines)
• 8 points : peut attendre deux Sprints (environ quatre semaines)
• 13 points : peut attendre un Sprint (environ deux semaines)
• 21 points : l'urgence la plus élevée, vous devez prendre ce problème pour le prochain Sprint

Réduction des risques | Valeur de création d'opportunités (RR | OE)

Tâches pour éviter ou réduire les risques technologiques ou métier. Les exemples incluent la refactorisation du code, la mise à jour de la base de données, la sécurité ou l'audit fiscal — quelque chose que vous devez faire pour assurer le bon fonctionnement d'un produit.

La réduction des risques et la création d'opportunités vous aident à mettre en évidence les tâches qui peuvent ne pas générer de revenus immédiatement mais bénéficient au long terme. Certaines solutions éliminent les risques techniques ou juridiques et vous font économiser de l'argent plus tard. D'autres peuvent ouvrir des portes pour des améliorations ultérieures qui augmenteront considérablement le nombre de clients potentiels.

Questions à répondre : Si la tâche commence par une description de risque, quelle sera l'ampleur de l'impact de ce risque ? Quelle probabilité ?

Évaluation de la réduction des risques avec la séquence de Fibonacci

• 1 point : ne fournit aucune réduction de risque du tout
• 2 points : réduit la probabilité d'un risque le plus faible, probabilité de gravité la plus faible
• 3 points : réduit la probabilité d'un risque faible, probabilité de gravité faible
• 5 points : réduit la probabilité d'un risque modéré, probabilité de gravité modérée
• 8 points : réduit la probabilité d'un risque modéré à élevé, probabilité de gravité élevée
• 13 points : réduit la probabilité d'un risque très élevé, probabilité de gravité très élevée
• 21 points : peut réduire le risque d'un événement très impactant, une catastrophe qui est très susceptible de se produire

Taille de la tâche (Durée de la tâche)

La taille de la tâche est le seul facteur négatif et classe les tâches selon la complexité de réalisation. Il est impossible d'atteindre le ROI le plus élevé sans tenir compte des coûts en heures-personnes requis. La durée est également appelée story points, points de fonctionnalité, effort ou taille relative.

Questions à répondre : Combien de temps prendra la mise en œuvre ? Y a-t-il des dépendances qui peuvent rendre cela plus chronophage ?

Évaluation de la taille de la tâche avec la séquence de Fibonacci (story points)

• 1 point : aucun effort requis du tout. Nous ne pouvons pas diviser par zéro, donc notre estimation de taille de tâche doit commencer à 1.
• 2 points : la base d'estimation. Probabilité de 80 % qu'un jour suffise pour coder et un jour pour tester et valider pour une itération de deux semaines.
• 3 points : une tâche représentant environ un quart des efforts de votre Sprint
• 5 points : quelque chose représentant la moitié de votre itération. Probabilité de 80 % que la tâche prendra 5 jours ouvrables pour coder et un jour pour tester et valider pour une itération de deux semaines.
• 8 points : probabilité de 80 % qu'une tâche soit développée et testée dans les deux semaines (une itération/Sprint)
• 13 points : entre une et deux itérations
• 21 points : « Estimations Buzz Lightyear », quelque chose qui prend deux Sprints ou même plus (« vers l'infini et au-delà »). D'après mon expérience pratique de travail avec les équipes, vous évaluerez beaucoup d'idées qui dépassent une itération et devraient être divisées en morceaux plus petits.

La formule finale pour calculer le score WSJF :

Score WSJF = (Valeur métier + Criticité temporelle + Réduction des risques | Création d'opportunités) / Taille de la tâche

Personnalisez les critères pour votre équipe

Dans le cadre Scrum standard, l'estimation des story points de chaque équipe — et la vélocité résultante — est une préoccupation locale et indépendante. Voici un point de départ pour votre processus d'évaluation. Vous pouvez l'appliquer depuis le modèle WSJF Ducalis et modifier les descriptions des critères.

Il n'y a pas de définition unique correcte pour une échelle. Si vous et votre équipe êtes confus par un terme — changez-le ! Ducalis est assez flexible à cet égard.

Itérations

Le cœur des processus agiles est constitué des blocs de construction de base appelés itérations ou Sprints. Chaque itération est une période fixe standardisée pendant laquelle les équipes agiles fournissent une valeur incrémentale.

Événement de planification d'itération (Product Increment)

Chaque itération doit commencer par une liste claire de priorités. Avant cette planification, vous devriez avoir un Backlog évalué. Les équipes peuvent souvent passer toute la semaine entre les cycles de développement pour l'évaluation, la priorisation et la planification. Ensuite, déployez de la valeur en itérations courtes (Sprints).

Ducalis peut économiser toute cette semaine pour votre équipe grâce à un processus d'évaluation asynchrone. Fixez un jour de planification, et Ducalis fera le reste. Vous pouvez suivre la progression de l'évaluation avec le rapport de progression de l'évaluation de l'équipe.

Pour motiver vos coéquipiers à évaluer à temps, offrez un soutien avec des messages encourageants. Accédez aux paramètres d'habitude de priorisation et définissez un message gratifiant pour les coéquipiers qui terminent leur évaluation à temps avant la réunion de planification d'itération à venir.

Le pouvoir de la réévaluation

Les priorités absolues, l'urgence et les valeurs métier sont des produits périssables. Il y a tellement d'informations — nouvelles demandes des clients, bugs, dettes techniques, nouvelles réglementations, idées fantaisistes et bien plus encore.

Toute l'idée de SAFe est de s'adapter d'une nouvelle manière à un monde en évolution rapide. L'environnement d'une entreprise change toutes les cinq itérations (un PI). Par conséquent, il est fortement recommandé de réinitialiser les scores d'évaluation.

Dans un système basé sur les flux, la mise à jour continue des priorités fournit les meilleurs résultats économiques. Le séquençage des tâches plutôt que le retour sur investissement théorique et individuel des tâches produit le meilleur résultat dans un tel contexte de flux.

Un avantage secondaire de la réévaluation du Backlog est le raffinement/nettoyage du Backlog. En réfléchissant à chaque élément du Backlog, vous obtiendrez des idées sur la façon de fusionner, mettre à jour ou supprimer votre tâche car certaines informations seront devenues obsolètes pour une raison quelconque. D'après l'expérience de hi.ducalis.io, nous supprimons 2 % à 5 % de nos éléments de Backlog à chaque cycle de réévaluation.

Pour configurer les cycles de réévaluation :

1. Cliquez sur Meeting in # days (Réunion dans # jours).
2. Faites défiler jusqu'à la section d'expiration des scores.

Par défaut, les scores d'évaluation de votre équipe expireront après le début du prochain cycle PI.

Par défaut, le Sprint dure deux semaines. Personnalisez-le dans la section des habitudes de priorisation.

Conseil pro

Si vos scores ont expiré et que vous n'avez pas terminé le PI précédent, vous pouvez toujours restaurer vos scores et prolonger la période de priorisation.

Priorisation collaborative

L'estimation agile est un sport d'équipe. Chaque équipe agile comprend cinq à onze membres. Invitez votre équipe agile (équipe interfonctionnelle) au processus de priorisation.

Lorsqu'une équipe estime le Backlog du produit, elle ne sait pas qui travaillera sur chaque tâche. Les équipes déterminent généralement cela pendant la planification d'itération (Sprint).

C'est pourquoi toute l'équipe agile évalue chaque élément du Backlog du produit.

Réduire les biais

Toute l'équipe doit comprendre la logique derrière l'attribution des story points pour atteindre une pratique cohérente. Tous les membres de l'équipe votent sans être influencés par les autres membres de l'équipe. Une pression extérieure ou un travail d'équipe insuffisant peut rapidement gonfler les story points, affectant les prévisions.

Parfois, les réunions de priorisation peuvent être dirigées par la personne la plus bruyante dans la pièce. Cela signifie que vous pouvez vous interférer les uns les autres pendant la session d'évaluation. Laissez tout le monde prioriser à son propre rythme.

Choisir 'le bon impact'

Nous avons parlé de l'impact métier au début de l'article. Mais quelles réponses obtiendrez-vous si vous posez à différents rôles une question simple « Quelle est la chose la plus impactante que nous devrions faire ensuite ? » Par exemple, je parie qu'un développeur vous dira « base de données plus rapide », un commercial dira « une demande de fonctionnalité pour le plus gros client », et un chef de produit demandera « nouveau message de rétention », etc.

Il est presque impossible de comparer ce qui est le plus impactant. Cependant, c'est une bonne chose à considérer pour chaque équipe agile et c'est précisément ce que Ducalis peut gérer pour vous.

Collecter différentes opinions

Les cadres de priorisation sont excellents pour garder l'émotion et la politique hors d'une décision afin que vous puissiez vous fier aux faits à la place. Cependant, lorsque vous priorisez seul, vous êtes toujours biaisé. Empruntez la technique de planification poker pour la priorisation. Avec Ducalis, invitez chaque membre de l'équipe à la priorisation.

Pour inviter des coéquipiers :

1. Ouvrez les paramètres des critères.
2. Invitez des coéquipiers à votre équipe d'évaluation partagée.

Cela fournit à chaque coéquipier sa propre liste d'évaluation pour une estimation indépendante.

Spécifier les critères pour chaque rôle

Disons que vous devez développer une nouvelle fonctionnalité pour votre site web. Vous avez au moins trois rôles — designer UX, front-end et back-end — tous ont une taille de tâche différente pour cette fonctionnalité. L'UX a besoin d'une taille de tâche de 3 jours, le front-end a besoin d'un jour et le back-end a besoin de cinq jours. Quelle est la taille de la tâche pour le projet total ?

Le problème n'est pas le calcul ; votre équipe devrait trouver un créneau horaire pour en discuter. Dans un monde remote-first, cela signifie un appel Zoom supplémentaire et une discussion. Plus de travail autour du travail.

Ducalis peut gérer cela pour vous avec une approche de priorisation asynchrone.

Pour attribuer des critères par rôle :

1. Ouvrez les paramètres des critères.

2. Attribuez à chaque utilisateur un critère à estimer en fonction de son expertise.

   

Après cela, chaque membre de l'équipe évaluera les éléments du Backlog avec son ensemble de critères, dont il est responsable de l'estimation.

Quand tout le monde participe, cela augmente l'adhésion

L'effet secondaire de la priorisation collaborative est que les coéquipiers comprennent mieux ce qui se passe avec le produit. Nous savons quels défis, demandes et idées nous avons et pourquoi certains sont plus importants que d'autres. Cela augmente le moral et l'implication de l'équipe.

Normaliser les scores

Un peu de normalisation se produit grâce à la pratique régulière, aidant à garantir que tout le monde dans l'équipe fait les mêmes hypothèses derrière le dimensionnement. Par exemple, si une personne dimensionne un élément à « 2 », mais qu'une autre personne le dimensionne à « 8 », étant donné qu'elles partagent des capacités similaires, elles ont interprété l'exigence différemment ou l'ont abordée sous différents angles. Lorsque cela se produit, les développeurs collaborent avec le Product Owner pour clarifier les hypothèses et convenir d'une taille. (Cela ne doit pas nécessairement être un consensus — les gens peuvent accepter d'être en désaccord.)

Pendant qu'une équipe apprend ce que l'échelle de Fibonacci signifie pour elle, avec son ensemble unique de compétences, d'ancienneté et de connaissances du domaine, il est utile de comparer les nouvelles demandes au travail terminé avec des similitudes partagées. Par exemple, lorsqu'un nouvel élément se voit attribuer une valeur de story point de 5, comparez-le à des choses similaires de la même taille et ajustez les points en conséquence.

Avec Ducalis, vous pouvez rapidement vérifier le rapport d'alignement de l'équipe pour obtenir une carte thermique des désaccords. C'est un autre outil pour la priorisation asynchrone au lieu d'organiser une session de planification poker, où la majorité des estimations n'auront besoin d'aucune discussion du tout.

Diviser en morceaux plus petits

L'un des plus grands malentendus sur WSJF est qu'il peut concentrer votre équipe uniquement sur les tâches faciles (gains rapides). Au lieu de cela, plus la taille de la tâche est petite pour une tâche particulière, plus le score de priorité est élevé et plus la tâche sera classée haut.

Utilisez une matrice pour découper votre Backlog en morceaux et décider quoi faire avec vos tâches.

Grâce à la pratique du raffinement — diviser le travail en morceaux plus petits et plus précieux — les développeurs continuent à acquérir des connaissances. À mesure que chaque demande devient plus petite et que l'on en sait plus, ils revisitent continuellement la taille. Par conséquent, il est bon de fournir trois points de contact pour aider l'équipe avec la conception, le développement et les dépendances émergents.

Conseils pratiques

• N'essayez pas d'être trop précis. Si vous avez une tâche d'une heure, n'ayez pas peur de définir une base pour un jour. Tout sera compensé et équilibré à long terme.

• Arrondissez les estimations à la valeur suivante.

• Cependant, la décision finale reste au professionnel du produit responsable du séquençage des éléments dans le Backlog en question. Des facteurs tels que les échéances réglementaires, la fragilité du système hérité ou la construction d'une base pour les fonctionnalités futures peuvent être difficiles à mettre en termes financiers mais doivent néanmoins être pris en compte.

Ressources connexes

• Modèle Google Sheets WSJF

---

hi.ducalis.io n'est pas associé à Scaled Agile Framework ou SAFe. Lisez leur vision et leur manifeste sur https://www.scaledagileframework.com/