Qui dit travail en agile, dit travail en mode capacitaire. C’est-à-dire nécessité de faire des choix, de devoir prioriser les demandes faites à une équipe IT afin qu’elle mette, petit à petit, les fonctionnalités à disposition des utilisateurs. Mais comment effectuer cette priorisation ? Selon quels critères ?
Voici un retour d’expérience sur un atelier que j’ai effectué en 2020 avec les représentants métiers d’une équipe Produit que j’accompagnais : « La maman de T’choupi part au travail. »
NB 1 :
L’atelier parle de « maman » car je suis une femme, mère de famille mais l’atelier peut tout autant s’appeler « Le papa de T’choupi part au travail. »
Les exemples cités dans cet atelier ne sont que fictifs et toute ressemblance avec des personnes ou des situations ayant existé ne saurait être que fortuite. 😉
NB 2 :
Mes 2 sources d’inspiration :
Il est 8h du matin un jour de semaine. Dans 30 minutes, il est temps de partir pour déposer les enfants et il vous reste encore une liste de choses que vous vouliez effectuer de matin avant de partir.
Vous savez que vous ne pourrez pas tout faire, il faut donc choisir les tâches à effectuer absolument ce matin. Pour cela il vous faut ordonner votre liste.
Ce qui a le plus de valeur (pour vous) ce matin se retrouvera en haut de liste.
C’est ce qu’on appelle prioriser par la valeur.
“Sortir le chien” est dans le haut de votre liste car le chien a besoin de sortir faire ses besoins tous les matins (c’est naturel et obligatoire). Cette tâche a une forte valeur à l’instant présent.
Puis le repas de midi de la petite qui ne peut pas passer la journée sans manger (la aussi c’est un besoin naturel et obligatoire).
Vient ensuite l’habillement des enfants qui ne peuvent pas sortir en pyjama.
Signer le carnet sinon le grand ne pourra pas effectuer sa sortie (promenade au parc avec sa classe).
Pour finir les poubelles sont à sortir pour ne plus empester la cuisine.
Au contraire bien qu’il soit important de faire la vaisselle, ranger la chambre des enfants ou arroser les plantes, il ne s'agit peut-être pas, à ce moment précis de la journée, des actions les plus “importantes” (prioritaires). Elles se retrouvent donc en fin de liste.
Et voilà vous avez réduit votre liste. Vous avez désormais la liste des choses qu’il vous faut absolument faire ce matin.
Et dans la vie d'un projet IT ? Cet exercice correspondrait à la mise en place d’un atelier pour définir la valeur métier de chaque fonctionnalité à réaliser. Valeur Métier : quelle est la valeur apportée par la fonctionnalité, pour le client ou l’entreprise ? Nos utilisateurs vont-ils préférer ceci à cela ? Quel est l’impact sur nos activités ? (Par exemple, estimation en points via une suite de Fibonacci) Mais que faire si 2 fonctionnalités ont la même valeur ? Comment choisir un ordre de réalisation ? Cette priorisation ne peut pas permettre, à elle seule, l’ordonnancement des activités. En général, on commence à étudier les interactions potentielles des fonctionnalités entre elles. Mais le plus important est de savoir si on aura le temps de les effectuer. Se pose donc la question de l’estimation du temps qu’il faudra pour réaliser la fonctionnalité. Temps dépendant de la complexité ou de l’effort pour mettre en œuvre cette fonctionnalité. On parle également de taille de la fonctionnalité. |
Revenons à l'exercice.
Vous avez votre liste d’activités à effectuer. La question importante consiste à savoir si ces activités ne sont pas trop « grosses », ne durent pas trop longtemps et si vous pourrez les finir dans le temps qu’il vous reste, 30 minutes à peine.
Voila ce que donne l’estimation de durée pour effectuer vos 6 activités prioritaires.
Les autres activités de la liste n’étant pas identifiées comme apportant de la valeur maintenant, vous ne prenez pas la peine de les estimer.
Sans compter que vous avez déjà un total de 27 minutes d’activités à effectuer pour un “crédit” temps de 30 minutes (il est 8h et vous devez partir à 8h30).
Vous avez donc la liste des activités priorisées et en plus elle tient dans le timing. Vous avez même un petit rab de 3 minutes. C’est parfait !
Et dans la vie d'un projet IT ? Les membres de l’équipe Agile estiment en points de complexité l’effort de mise en œuvre des différentes fonctionnalités et comparent cette estimation à leur capacité à faire. NB : Travail effectué sur les User Stories à l’échelle d’un sprint, les fonctionnalités à l’échelle d’une version ou pour une roadmap moyen terme. |
Dans l'exercice :
En 30 minutes, il est possible de faire l’ensemble des activités identifiées comme devant être terminées ce matin. Super, ça va le faire !
… Enfin dans un monde idéal…
Et voilà, il vous faut 20 minutes de plus que prévu pour réaliser vos activités du matin.
Et encore si vous n’étiez pas en retard sur le repassage du linge …
Vous avez remarqué que cette dernière tâche n’était pas dans la liste « à faire » ? Et pourtant il faut la réaliser…
C’est le fameux imprévu !
En synthèse, sur votre liste priorisée par la valeur, vous n’arrivez à réaliser que 3 des 6 tâches prévues (et encore la 3ème ne sera pas terminée).
Alors cette priorisation par la valeur, une fausse bonne idée ?
La tâche “sortir le chien” a été mise en tête de votre liste car le chien a besoin de sortir faire ses besoins tous les matins (c’est naturel et “obligatoire”). Cette tâche a une forte valeur à l’instant présent mais le problème c’est que la sortie du chien dure 15 minutes soit la moitié de votre “forfait” de 30 minutes avant de déposer les enfants.
Si vous la faites en premier, il ne vous reste que 15' pour tout le reste. Et en cas d’imprévu, vous n’aurez pas de marge de manœuvre.
Donc, la priorisation par la valeur c’est bien, mais elle ne prend pas en compte le risque à ne pas faire une tâche. Il est possible de faire mieux !
Et dans la vie d’un projet IT ? Cas 1 : Les 2 fonctionnalités ont la même taille, sont aussi complexes à mettre en œuvre, nécessitent le même temps de travail -> Ordre de priorisation F2 puis F1. On se base simplement sur la valeur apportée, la plus grande valeur en premier. Cas 2 : Les 2 fonctionnalités ont la même valeur, le temps pour les obtenir est différent -> Ordre de priorisation : F4 puis F3. On se base simplement sur la durée de mise à disposition pour prioriser. Intuitivement, notre choix de priorisation va vers ce qui apporte le plus de valeur et le plus rapidement.Cas 3 : C'est le cas le plus courant et le plus complexe. Comment prioriser, ordonnancer ? Commencer par ce qui apporte le plus de valeur (F3 / F2 / F1) ? Ou au contraire, commencer par ce qui prend le plus de temps pour l’avoir dans un délai raisonnable (F1 en premier) ? Ou encore commencer par ce que l’on peut avoir le plus rapidement (F2 / F3 / F1) (et ainsi ne pas tomber dans le piège de l’exercice) ? Un mélange de tout ça ? |
Quelques explications … Le « Weight Shortest Job First » ou WSJF est un modèle Agile destiné à déterminer la priorisation des fonctionnalités (ou de User Stories) présentes dans le Product Backlog. Sa traduction pourrait être « le travail le plus lourd et le plus court en premier”. Cette méthode WSJF provient du framework Lean-Agile SAFe. SAFe est un framework agile très complet destiné à être déployé sur l’ensemble d’une entreprise (Framework d’agilité à l’échelle, équipes de plus de 50 personnes). WSJF est un outil qui peut être utilisé seul, par le Product Owner, quelle que soit la taille du projet et de l’équipe. Cet outil est repris par de nombreuses équipes Agile, dans de nombreuses entreprises, car il permet de limiter les impacts d’une mauvaise priorisation en cas d’imprévus. L’hypothèse de cette méthode est que toute fonctionnalité, qui n’est pas livrée dans les temps, a un coût, un coût de retard. Une mauvaise priorisation du Product Backlog risque donc d’entraîner la multiplication de ces coûts. Même s’ils ne sont pas importants pour chaque fonctionnalité, le cumul peut s’avérer désastreux. L’objectif du WSJF est donc de réduire au minimum ces coûts et d’apporter un maximum de valeur ajoutée à l’issue d’un sprint. Le WSJF est particulièrement utile pour aider le Product Owner à trancher lorsqu’il est difficile de décider entre deux fonctionnalités similaires (en termes d’apport de valeur et de temps de mise en œuvre), laquelle doit être développée en priorité. Si deux fonctionnalités ont la même valeur, mais que l’une des deux va prendre moins de temps à développer, la solution est simple, c’est cette dernière qui sera prioritaire. En revanche, s’il existe une fonctionnalité dont le délai de développement est encore plus court, mais qui n’a pas été jugée prioritaire jusque-là, un arbitrage va être nécessaire. C’est dans ce cas que le WSJF va apporter la plus grande aide. Le WSJF est calculé pour chaque fonctionnalité présente dans le Product Backlog afin de lui attribuer une valeur et déterminer les priorités. Plus le WSJF d’une fonctionnalité sera élevé, plus elle sera prioritaire dans l’ordre des réalisations. Pour en savoir plus : https://www.scaledagileframework.com/wsjf/ |
Retour à l’exercice.
Que faire avec la tâche « sortir le chien » ?
Quelqu’un d’autre pour promener le chien ?
Vous avez toujours la possibilité de faire appel à votre conjoint.e. A lui/elle de sortir le chien pendant que vous vous focalisez sur d’autres tâches.
Cela équivaudrait dans la vie d'un projet IT à faire ajouter ponctuellement d’autres membres pour renforcer l’équipe ou à faire appel à une autre équipe. Mais cette solution n’est pas sans impact. |
Impact sur les activités du conjoint a minima. Pendant la sortie du chien, d’autres activités ne se font pas.
L’option de faire appel à un dog sitter, promeneur de chien est également possible. Mais il y aurait des impacts financiers (salaire) mais également de temps de montée en compétence des habitudes du chien.
Si l’on revient à la méthode WSJF, l’autre solution serait donc de s’attacher au cout du retard, au risque à ne pas faire cette activité ce matin.
Pour cette activité, il est plutôt faible (voire moyen) : Si vous ne sortez pas le chien ce matin, il risque de faire pipi dans la maison. C’est gênant mais finalement c’est moins important que le risque à ne pas habiller ses enfants pour aller à l’école (enfin je pense).
Du coup la valeur du coût de retard risque d’être assez basse.
Le temps en revanche (15') est plutôt long. Cette tâche a donc un score WSJF très faible… C’est donc une tâche à prioriser en “bas” de votre liste, du Backlog d’activités.
Finalement si on y réfléchi bien, si vous sortez le chien en dernier :
Que se passe-t-il pour les autres tâches de votre top liste ?
Quel est le cout du retard (puis le WSJF) de chaque tâche (sur une échelle de 1 à 20) ?
Le Cout de retard (donc le risque à ne pas faire au bon moment) de la tâche “sortir le chien” est plus important que les tâches “sortir la poubelle” et “signer le carnet de correspondance”…. mais comme sa durée d’exécution est beaucoup plus longue, le WSJF est plus petit… la tâche est donc moins prioritaire.
Et dans la vie d’un projet IT ? Le coût du retard est constitué de 3 éléments : Cout de retard = valeur métier + urgence à faire + Risque à ne pas faire OU opportunité à faire Valeur Métier : quelle est la valeur apportée par la fonctionnalité, pour le client ou l’entreprise ? Nos utilisateurs vont-ils préférer ceci à cela ? Quel est l’impact sur nos activités ? -> Objectif : Estimer la valeur métier/utilisateur de chacune des fonctionnalités. Sans tenir compte ni des contraintes planning (pilotage), ni de la complexité, ni des interactions potentielles avec les autres fonctionnalités. Urgence à faire : Faut-il faire vite ou pas ? Y a-t-il une date limite pour mettre cette fonctionnalité à disposition du client/de l’utilisateur ? La valeur diminue-t-elle avec le temps ? Y a-t-il une pénalité potentielle ou un autre impact négatif si nous retardons ? Y a-t-il un délai fixe ? Les clients vont-ils nous attendre ou passer à une autre solution ? Y a-t-il des jalons sur le chemin critique touchés par le décalage ? Quel est l'effet actuel (de ne pas avoir cette fonctionnalité) sur la satisfaction client ? -> Objectif : Estimer la criticité en termes de planning en incluant les impacts techniques sur les autres fonctionnalités, les attentes utilisateurs, les jalons métier. |
Et dans la vie d’un projet IT ? Cout de retard = valeur métier + urgence à faire + Risque à ne pas faire OU opportunité à faire Risque à ne pas faire / opportunité à faire : Qu'est-ce que cela fait d'autre pour notre entreprise ? Réduit il le risque de cette livraison ou d’une future livraison ? Y a-t-il une valeur dans les informations que nous recevrons ? Cette fonctionnalité permettra-t-elle de nouvelles opportunités commerciales ? -> Objectif : Estimer les opportunité techniques, commerciales, ... |
A noter : Lors de la création de cet atelier, nous étions en 2020 en période de confinement avec donc nécessité de remplir une attestation de sortie y compris pour accompagner les enfants à l’école ou chez la nounou chaque matin. La génération de l’attestation de sortie était obligatoire mais les contrôles rares.
Lors de la 1ere étape de priorisation de la liste des activités, l’activité « Générer l’attestation de sortie (confinement oblige) » était en fin de liste. En effet, cette attestation n’apportait pas de valeur pour emmener les enfants à l’école. Cependant ne pas la remplir pouvait être risqué en cas de contrôle de police.
En tenant compte des critères valeur métier & urgence à faire pour estimer l’ensemble des tâches (l’ensemble des tâches de la liste initiale), cette activité se retrouvait alors en top de priorité. En cas de contrôle, en plus du prix de l’amende, le risque était fort d’arriver en retard et d’empêcher votre fils de participer à sa sortie (et il vous en aurait beaucoup voulu de manquer la sortie et de contrarier son plan invitation de copains).
Retour à l’exercice ...
L’activité « Faire la lessive » ne figurait pas dans votre top priorisé des tâches à finaliser ce matin à 8h30 quand seule la valeur attendue avait été étudiée. Mais si l’on tient compte des 2 critères « valeur métier » & « urgence à faire » ce n’est plus cas.
Il faut donc reprendre l’exercice depuis le début pour estimer l’ensemble de vos tâches (les 14 initiales).
La 1ere étape est d’ordonnancer l’ensemble des tâches de la ToDo afin d’en calculer le coût de retard et la taille et ainsi en déduire le WSJF qui permettra de les prioriser.
Mettre en route une lessive : Votre fils vous en voudra beaucoup trop s’il ne peut pas rejoindre ses copains en fin d’après-midi.
Arroser les plantes : On est en hiver. Elles peuvent attendre. Elles ne vont pas se faner d’ici ce soir.
… etc …
Ce qui donne en nouvelle liste priorisée :
Le chien ne pourra pas effectuer une promenade de 15 minutes mais une dizaine de minutes c’est déjà bien …
Et dans la vie d’un projet IT ? Une 1ère passe de priorisation de l’ensemble des fonctionnalités du Backlog est à effectuer en tenant compte des 3 éléments du coût de retard, et non pas seulement de la valeur métier. Cet ordonnancement des fonctionnalités est à effectuer paramètre par paramètre pour l’ensemble des fonctionnalités, en relatif. |
Les avantages Pourquoi une priorisation WSJF est-elle plus intéressante qu’une simple priorisation par la valeur ? Dans une situation idéale, on aura le temps de tout faire et donc les 5 fonctionnalités seront délivrées. Mais en cas d’imprévu ? La preuve en image … NB : pour simplifier les schémas, j’ai effectué un raccourci dans les graphiques Taille = Temps Cas 1 : tout se passe bien. Aucun imprévu à déplorer, tout s’est passé comme prévu dans le plan. L’ensemble des fonctionnalités sont mises en œuvre. La totalité de la valeur métier est délivrée. Cas 2 : Un imprévu arrive très tôt dans le projet Avec la priorisation par la valeur métier, rien n’est délivré. Contrairement à la priorisation WSJF qui permet de disposer d’au moins une fonctionnalité et de 8 points de valeurs. Cas 3 : Un imprévu arrive plus tardivement dans le projet La différence en termes de valeur délivrée entre les 2 priorisations est moins grande mais il est visible que la priorisation WSJF permet de limiter les impacts des imprévus qui apparaitront (quasi) surement au cours du projet. Plus l’incertitude est grande (comme c’est le cas au démarrage d’un projet) et plus la priorisation WSJF montre donc son intérêt. |
Pour en savoir plus : https://www.scaledagileframework.com/wsjf/
L’atelier s’est terminé par une séance de questions / réponses concernant la compréhension de la méthode et l’identification de ses avantages. L'objectif de l'atelier a été atteint. Les représentants métiers ont adhéré. (Voir également un complément en commentaires) |
Voici en attaché, le support pdf complet de l'atelier :