Qu’est-ce la Business Value ?
Comme son nom l’indique, la Business Value est la valeur business d’une demande. Les métiers pourront donner une valeur business à chacune des user stories afin d’aider le Product Owner à prioriser son Backlog.
Petit rappel
Il est important dans les méthodes agiles de prioriser par la valeur. Nous voulons délivrer plus de valeurs au début du projet pour obtenir les feedbacks les plus importants le plus tôt possible. Pourquoi ?
Si vous connaissez l’Iron Triangle Agile (voir ci-dessous), nous avons deux axes fixes dans les méthodes agiles : les coûts et les délais. Mais nous travaillons tout le temps avec un scope variable.
Donc, nous ne savons pas vraiment ce que nous allons livrer à la fin du projet. Mais nous voulons offrir le meilleur produit pour les clients. Pour cela, nous essaierons de fournir un maximum de valeur le plus tôt possible afin de nous assurer d’avoir le meilleur produit au final.
Voici une courbe qui représente la situation idéale à obtenir pendant le projet:
Nous avons une première étape de rodage (le temps est variable selon les équipes), mais nous essayerons ensuite de fournir le maximum de valeur business.
Comment noter les user-story de façon simple ?
Lors d’un atelier ou de la réunion de priorisation si vous la faites, le Product Owner (PO) va demander aux métiers de mettre une Business Value à chacune des user-story.
Il proposera une échelle de 100 à 1000 aux métiers. Quand les métiers sont d’accord sur la user-story, on l’indiquera sur le post’it de cette façon en rouge :
Cette Business Value va permettre au Product Owner de définir un ROI (Return on Investment) sur chacune des user-story calculé de cette façon comme nous l’avons vu dans l’article des « quick win » (Les quick wins dans le monde Agile) :
ROI = Business Value / Complexité.
Le Product Owner va alors le noter sur le post’it afin que ce ROI soit visible par tout le monde :
Le ROI peut vraiment être intéressant car il permet éventuellement de faire un choix dans les priorisations. Il peut-être intéressant de faire passer des tickets avec un fort ROI car ils sont en général rapides à traiter et leur Business Value est assez forte.
En le traitant rapidement, le Product Owner gagnera probablement en estime chez le métier qui a fait cette demande. Plus le Product Owner est apprécié, plus il a de chance d’être soutenu par les métiers lors des périodes difficiles.
Ne l’ignorons pas, le Product Owner doit avoir également une stratégie de séduction si il veut continuellement améliorer son espace de travail.
Premier problème rencontré
Si vous ne rencontrez pas ce problème dans la définition des Business Value, vous n’aurez pas besoin d’aller plus loin dans l’atelier. En général les problèmes arrivent quand nous avons plusieurs clients pour notre équipe Scrum et que l’équipe gère plusieurs projets (voire des micro-demandes comme des petites évolutions ou des bugs).
Le premier problème que le Product Owner rencontre souvent, c’est que l’ensemble des métiers mettent une Business Value forte sur leurs tickets en croyant qu’ils passeront du coup avant.
Ce n ‘est pas rare de voir dans les grandes entreprises des métiers qui se mettent en concurrence face au Product Owner parce que l’ensemble de leurs demandes est dix fois supérieure à la capacité de faire de l’équipe Scrum. Ils pensent ne pas avoir le choix que de trouver des combines pour pouvoir voir leurs demandes se réaliser.
Utiliser un Board pour les Business Value
La mise en place de ce Board de Business Value (BV) devra être fait dans une réunion appelée la Priority Meeting si vous ne le faites pas déjà. On rassemble les métiers chaque semaine pour une petite session de priorisation ; le Product Owner utilisera ce board comme support.
Le Product Owner va pouvoir forcer l’ensemble des métiers à mettre les bonnes BV en imposant le placement des post’it sur un board dédié à cet effet :
Les métiers devront mettre leurs demandes dans les colonnes de cette façon ce qui déterminera automatiquement les BV de chaque user-story. Ils ne pourront utiliser une deuxième ligne uniquement si la première ligne est complète.
Le but de ce board est de forcer les métiers à prioriser leurs demandes ensemble voire de discuter en cas de désaccord. Le but n’étant pas de traiter l’ensemble du backlog mais de traiter les demandes les importantes aux yeux des métiers.
Conclusion Business Value
Ayant déjà expérimenté cette méthode, je peux vous garantir qu’elle aide vraiment à prioriser correctement vos Sprint backlog.
Il existe de nombreuses techniques pour améliorer les priorisations dont celle des Business Value. N’hésitez pas à nous partager vos propres techniques en commentaire.
Bonjour,
Votre blog est excellent !
Dans cet article, la BV va 0 à 1000.
Dans l’article des QW, la BV va de 100 à 1000. Pourquoi cette différence ?
Par ailleurs, existe-il une échelle pour la complexité ?
Bien à vous,
Jean-Claude Sudre
Bonjour,
C’est une erreur de ma part. On considère qu’une user-story apporte toujours de la valeur donc je propose en général de 100 à 1000. Je viens de corriger le 0 à 1000 de cet article.
Moi en général pour les points d’effort (le terme complexité est à éviter car confusant, je change au fur et à mesure sur le blog d’ailleurs), je propose aux équipes d’aller de 1 à 13…
Je conseille fortement d’éviter le 0 car même si parfois il semble y avoir quasiment aucun travail à faire, le moindre problème peut amener à un effort non prévu. Maintenant certaines équipes vont à 21 voire plus. C’est à l’équipe de définir son référentiel mais il est vrai que 21 peut amener à imaginer que la user-story peut d’avantage être découpée. Le plus important c’est que l’équipe définisse elle même son référentiel 🙂
N’hésite pas si tu as d’autres questions surtout.
Bonjour et merci pour ce blog interessant. « Ils ne pourront utiliser une deuxième ligne uniquement si la première ligne est complète. » Pourquoi? merci de votre explication 🙂
Pour les forcer à ne pas mettre la même valeur à chaque demande. C’est une recommandation car on voit souvent les demandeurs mettre le maximum à 80% de leurs demandes lol
Bonjour,
Super article et super blog.
J’ai tout de même une question sur le board. Si je force les métiers à « étaler » les user story entre 100 et 1000, j’aurais donc une user story avec une petite business value (à 100). Mais elle a une valeur à 100 non pas parce qu’elle n’est pas importante, mais parce que les autres users story que l’on a priorisé à ce moment là sont plus importantes.
Lors de la réunion de priorisation suivante, si je refais le travail avec d’autres users story, je peux me retrouver avec une US moins importante mais avec une business value plus élevée (puisque nous ne l’avons pas comparé aux mêmes users story que la semaine précédente).
Comment gérez vous ce cas ? est-ce que vous ré-évaluer la BV de la 1ere user story chaque semaine, tant que celle ci n’a pas été réalisé ?
Merci d’avance pour votre réponse
Bonjour Aurore,
L’objectif de ce board est surtout de rechallenger les utilisateurs (ou parties prenantes) pour qu’ils acceptent le fait que tout n’a pas une forte valeur. Mais le facilitateur peut éventualiser d’accepter des superpositions quand les participants justifient réellement les raisons et qu’elles sont comprises des autres.
Il ne faut pas hésiter à réestimer les valeurs si l’équipe en sent le besoin. Il y a le cas que tu dis, mais il peut aussi avoir des cas comme : la user story a moins de valeur car une story livrée précédemment répond partiellement au même besoin. Donc oui, si l’équipe veut réestimer, il n’y a aucune contre indication, bien au contraire. Une valeur bouge avec l’évolution du produit, du contexte, des feedbacks…
J’espère que ça répond à tes questions et si ce n’est pas le cas, n’hésite pas à me demander des précisions surtout.
Bravo pour le travail réalisé, ce blog est très riche !
Je travaille sur un moyen de prioriser des fonctionnalités au sein d’un bklg commun à plusieurs projets (phase transitoire vers un mode produit). Nous sommes parti sur le nombre de poste déployés pour estimer la BV. Mais le gain de temps (en production) pourrait être considéré (même si plus délicat à mesurer). J’aimerais aussi y intégrer la notion de temps (pour quand au plus tard) mais c’est encore subjectif. Je souhaite éviter que ce soit la plus grosse voix qui l’emporte. Aurais tu une liste de critères qui puisse être pris en compte dans la BV ?
Certains utilisent le RICE pour prioriser. Regarde si ça peut répondre à ton besoin : https://blog.myagilepartner.fr/index.php/2019/05/27/rice-pour-prioriser-notre-backlog/
Je vais faire un article ces prochains jours pour donner des pistes sur le sujet. En général, on trouve un coefficient basé sur des éléments communs. C’est un peu complexe au démarrage mais certaines équipes se familiarisent vite avec ce système.
Exemple simple à appronfondir:
(I) impact = nb de poste impacté / nb de poste total
(GT) gain temps = estimé de 1 à 10
(PL) priorité de livraison = 1 à 10
(E) point d’effort = de 1 à 13
Prio = (I x GT x PL) / E
C’est à affiner selon l’importance des 3 éléments que tu m’as donné mais certaines équipes font leur propre coefficient de priorisation. A tester et à affiner si ça vous semble être la solution.
Bonjour
J’ai testé votre tableau (100 à 1000) pour réaliser la BV avec les équipes métiers, puis réalisé la méthode poker planning (0 – 0,5 – 1 – 2 – 3 – 5 – 8- 20 – 40 – 100) avec l’équipe technique.
Ensuite j’ ai calculé le ROI (ROI = Business Value / Complexité) puis mettre ces éléments dans un tableau :
– non complexes et avec une forte valeur
– complexes mais avec une forte valeur
– non complexes mais avec une valeur moindre
– complexes avec une valeur moindre
J’obtiens un résultat qui n’est pas logique, : les US qui ont le plus de valeur business et sont complexe obtiennent un petit chiffre.
Je pense que je ne dois avoir loupé quelque chose dans le process.
Pourriez-vous svp me renseigner ?
D’avance, merci.
Cordialement,
Virginie
Bonjour Virginie,
Non en effet c’est logique. Plus c’est complexe à développer, plus il y a de chance que ce soit long à développer. Du coup le ratio de valeur que tu peux délivrer diminue. Cette priorisation a pour but de délivrer un maximum de valeur le plus tôt possible. Si une demande est complexe à être réalisée, ca sera du temps pris sur d’autres développement.