Dans l'écosystème Agile, qu'il s'agisse de Scrum ou de SAFe, l'équipe de développement excelle souvent à estimer la complexité technique via les Story Points. Cependant, le Product Owner (PO) ou Product Manager (PM) peine parfois à quantifier la Business Value (Valeur Métier) de façon tout aussi pragmatique. Pourtant, sans cette donnée, comment garantir le meilleur Retour sur Investissement (ROI) à chaque sprint ?
1. Pourquoi utiliser l'échelle de Fibonacci pour la Valeur ?
L'échelle de Fibonacci (1, 2, 3, 5, 8, 13, 21...) n'est pas réservée aux développeurs. Appliquée à la Business Value, elle oblige les parties prenantes (Stakeholders) à trancher. Une fonctionnalité ne peut pas être "un peu plus importante" qu'une autre ; la non-linéarité de Fibonacci force à créer de vrais écarts de priorisation.
2. La formule magique du ROI Agile
Une fois que le métier a attribué une Business Value (BV) à un Epic ou une User Story (US), et que l'équipe technique a chiffré les Story Points (SP), le calcul devient mathématique et indiscutable :
3. Un cas pratique pragmatique
- Epic A : Refonte de la page de paiement. Les stakeholders l'estiment critique : BV = 21. L'équipe estime l'effort technique élevé : SP = 13. ROI = 21 / 13 = 1.61
- Epic B : Ajout du paiement Apple Pay. Moins critique pour tous les utilisateurs : BV = 13. Mais très facile à implémenter grâce à une API existante : SP = 3. ROI = 13 / 3 = 4.33
Conclusion : Bien que l'Epic A ait une valeur absolue plus grande, l'Epic B offers un ROI presque 3 fois supérieur. Le framework impose donc de commencer par l'Epic B pour maximiser la création de valeur rapide (Quick Win).
En synthèse
L'adoption de ce système instaure un dialogue sain entre le métier et la tech. Elle dépersonnalise les débats ("Ma fonctionnalité est la plus urgente") au profit d'une approche empirique et maximisée sur la rentabilité produit.