Cadrage Agiles : Un outil simple pour valoriser et prioriser les besoins exprimés par les parties prenantes
Au sein des démarches Agiles, le Product Owner est responsable de maximiser la valeur du produit résultant du travail de l’Équipe de Développement (Source : Scrum Guide de la scrum.org)
En disant cela, nous disons également qu’il faut évaluerla valeurdes éléments du Product Backlog du ou des Squads, Scrum Teams, Feature teams et autres pizza Teams qui le développent et le maintiennent.
Certes, mais comment ?
L’article que je vous propose ici, ainsi que le l’outil Excel qui l’accompagne et que j’utilise depuis quelques années, vous aideront, je l’espère dans cet exercice
Introduction :
Partons du postulat que vous avez effectué les différents ateliers de capture du besoin et autres gestion des demandes, lesquels vous ont permis d’initialiser ou compléter votre Backlog Produit, avec des besoins clairs et concis
Vers la fin du cadrage d’une release de votre produit, de votre projet, ou lors de vos rituels d’affinage de Backlog, le petit outil Excel ci-dessous référencé, vous permettra de lister vos besoins et de les prioriser
Lien vers le Template Excel de priorisation par la valeur et le risque :
Cliquez sur le tableau
Cet outil combine deux méthodes de valorisation :
Première méthode :
Valeur = Bénéfice métier + Préjudice métier (Risque à ne pas faire) combiné à la difficulté / risque à faire via une matrice Valeur / Risque.
La priorité est alors définie comme suit :
P1 : ce qui a une forte valeur et qui est compliqué à réaliser
P2 : Ce qui a une forte valeur et qui est facile à réaliser
P3 : Ce qui a peu de valeur mais est facile à réaliser (Idéal pour des juniors ou pour faire plaisir à un chef à plumes)
P4 : Ce qui a peu de valeur qui est compliqué à réaliser : Ce que l’on ne réalise jamais
Seconde Méthode
Méthode WSJF de SAFe 4 : (Bénéfice métier + Urgence (Time Criticality) + Reduction du risque) / Nbre de Points de complexité (déterminés en Planning Poker) = WSJF = Weighted Shortest Job First
Vous pouvez utiliser l’une ou l’autre des deux méthodes en groupant / dissociant les colonnes comme suit :
Vous pouvez également utiliser les deux méthodes simultanément : Ceci vous permettra une meilleure réflexion sur les résultats de priorisation obtenus.
Dans ce cas triez le tableau selon la colonne « priorité » ou selon la colonne « WSJF »
Lors des ateliers de valorisation avec les métiers, ceux ci devront répondre à toutes les questions par sujet (en fait, se mettre d’accord sur la bonne réponse de la dropdown et l’indiquer au facilitateur de l’atelier : Le Product Owner) :
– Bénéfice métier,
– Préjudice métier,
– Urgence,
– Réduction du risque,
– Points (obtenus en atelier de planning Poker)
Vous remarquerez que les réponses aux 4 premières questions ont pour valeur 1, 2, 3, 5 et 8, ce qui vous permet d’utiliser les premières cartes du planning poker pour vos différents ateliers, et les rendre ainsi plus ludiques
Les ateliers nécessaires pour valoriser le tableau :
Cinq ateliers sont nécessaires, car le casting est différent pour chacun d’eux
1) Atelier de valorisation avec le métier
Triez préalablement vos besoins par priorité décroissante selon votre propre jugement de la valeur métier. Ceci rendra plus fluide les ateliers avec les métiers, et peut être incitera les métiers à identifier plus rapidement, ce qui selon eux est le MVP (Minimum Viable Product)
Invitez principalement les métiers, les autres parties prenantes, les sachants de votre équipe, un représentant de l’Architecture d’Entreprise, un représentant Ops ou DevOps, un représentant architecture applicative
Reformulez l’histoire de chaque besoin, et pour chacun d’eux affichez la liste à choix des colonnes :
– Bénéfice métier
– Préjudice métier
– Urgence
– Réduction du risque
Exemple : 
Suscitez la discussion entre les participants et obtenez un consensus sur chaque réponse induite par les 4 colonnes précédemment citées (Au début cela vous semblera un peu long, mais pas de panique, cela va s’accélérer au fur et à mesure du passage en revue de chaque besoin)
Au besoin planifier un ou deux ateliers supplémentaires pour terminer cette co-évaluation de la valeur métier (je vous conseille de limiter chacun des ateliers nécessaires à 2 heures maximum)
2) Atelier d’évaluation de la complexité / risque à faire
Invitez principalement les sachants de votre équipe, un représentant de l’Architecture d’Entreprise, un représentant Ops ou DevOps, un représentant architecture applicative
Reformulez l’histoire de chaque besoin, et pour chacun d’eux demandez aux participants si le besoin va être long et / ou compliqué à satisfaire. Choisissez la réponse en déroulant la liste à choix de la colonne « Risque de fabrication » . Cet atelier (généralement court : 1 heure) permet d’obtenir rapidement une idée de la complexité à faire. La question est un peu différente que celle posée lors du planning poker, car elle inclut le risque à faire (maitrise ou non de d’une technologie, outil etc.)
Suscitez la discussion entre les participants, et obtenez un consensus sur chaque réponse
3) Atelier de Planing Poker
On voit ici un autre bénéfice au planning poker : prioriser au regard du coût de la fonctionnalité pa rapport à sa valeur métier
Réalisez un atelier de Planning Poker, sur l’ensemble du Backlog, ou au moins sur le MVP, selon la recette de ce bon vieux Mike
N’hésitez pas à faire du « Story Splitting » si nécessaire (diviser le besoin initial en plusieurs besoins qui seront plus faciles à évaluer), si un besoin s’avère trop complexe à estimer
4) Triez vos besoins
Vous voici maintenant prêt à trier vos besoins selon leur priorité calculée
Soit selon la première méthode : colonne Priorité par ordre ascendant
Soit selon la seconde méthode : Colonne WSJF par ordre descendant
Observez ce que cela vous donne, comparez les deux méthodes, préparez vos questions complémentaires aux parties prenantes pour affiner si nécessaire
5) Atelier de revue et ajustement des priorités avec le métier
Et voici le moment critique : Expliquer à un ou des métiers pourquoi tel ou tel besoin ne se trouve pas en priorité 1, car il coûte un peu trop cher à réaliser : Vous pourrez peut être vous en sortir autour d’une bonne bière
Montrez en projetant le tableau sur votre rétro-projecteur favori, le résultat de la priorisation
Commentez, expliquez
Revenez si nécessaire sur les besoins posant problème, et n’hésitez pas à les couper en morceaux, afin encore une fois, de réaliser ce qui a réellement plus de valeur en premier
N’oubliez pas les exigences non fonctionnelles (NFRs) et notamment les exigences de niveaux de service :
Les exigences de niveaux de services représentent les qualités du produit que vous réalisez ou améliorez. Ces qualités répondent aux questions concernant la sécurité, la capacité, la disponibilité (etc …) pour votre produit
Vous retrouverez une liste des principales questions de ce type dans l’onglet « Exigences non fonctionnelles »
Réalisez un atelier spécifique sur ces questions avec les métiers, les autres parties prenantes, les sachants de votre équipe, un représentant de l’Architecture d’Entreprise, un représentant Ops ou DevOps, un représentant de l’architecture applicative
Valorisez les colonnes comme précédemment, pour l’onglet « Exigences fonctionnelles »
Trop d’ateliers ?
Je dirai que non : Chaque atelier est une occasion d’inspecter les éléments de votre Backlog avec un casting différent et un angle de vue différent
Lorsque j’anime ces différents ateliers, tout naturellement les éléments du Backlog sont reformulés, parfois corrigés, coupés en morceaux s’ils contiennent plusieurs idées (Story Splitting), ou tout simplement supprimés.
On gagne ainsi sur tous les tableaux, et l’ensemble des équipes et parties prenantes ont la même vision de ce qui va être construit, dans quel ordre, et pour quand (en gros, à +- 20% près)
Customisation de l’outil :
Lors des différents ateliers vus précédemment, il est important que les parties prenantes se sentent à l’aise pour répondre aux questions que vous leur présentez
Selon le type de produit évalué, les réponses présentées dans les différentes Dropdown peuvent s’avérer plus ou moins pertinentes
N’hésitez donc pas à en modifier le texte dans l’onglet « Paramètres » que vous portez ensuite cacher. Attention cependant de ne pas supprimer les chiffres : 1., 2., 3., 5., 8.
Si vous rajoutez des colonnes pour disposer de plus de questions afin de définir la valeur (Peines, Bénéfice entreprise en plus du bénéfice persona), pensez à agrandir la taille de la matrice, le calcul de la valeur pouvant être plus élevé
Pour finir :
Et maintenant il ne vous reste plus qu’à copier chacune des lignes priorisées dans votre référentiel Agile préféré (JIRA, Agile Manager, Trello, …)
Ajouter de nouvelles lignes :
Se positionner sur une cellule du tableau, puis