Voir la source de Les problèmes liés à l'estimation de la valeur métier

[[Category: Mike Cohn]]
[[Category: Portail Product Owner]]
Auteur : Mike Cohn<br />
Source : [http://www.mountaingoatsoftware.com/blog/the-problems-with-estimating-business-value The Problems with Estimating Business Value]<br />
Date : 19/09/2010<br />
----
Traducteur : Fabrice Aimetti<br />
Date : 02/07/2012<br />
----
Traduction :<br />
<br />
<span style="display: block; text-align: justify">De temps en temps, je vois des équipes qui souhaitent définir une "valeur métier" sur chacune des user stories. Ils le font pour une, voire deux raisons :</span><span style="display: block; text-align: justify"><br /> 

# être capable de mesurer la quantité de "valeur métier" livrée à l'organisation, en le visualisant sur un graphe sprint après sprint
# être capable de prioriser les user stories en comparant la valeur métier de chacune des stories par rapport à son coût.
</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Malheureusement, il y a quelques problèmes avec ce type de pratiques.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Premièrement, la valeur de petits bouts de fonctionnalités s'entremêle. Lorsque nous avons des fonctionnalités qui sont trop petites (comme doivent l'être des user stories), il est très difficile de définir une valeur précise sur chacune. Les économistes appellent cela le prix hédonique. L'exemple classique est de définir des valeurs sur les composants individuels d'une maison : taille, lieu, vue, ... Comment allez-vous valoriser chacune de ces caractéristiques de la maison ? Vous pouvez en savoir plus sur le prix hédonique sur [http://www.investopedia.com/terms/h/hedonicpricing.asp#axzz1zUnPt2fL Investopedia] et cet exemple de [http://www.bls.gov/cpi/cpidryer.htm prix des séchoirs à vêtements] montre combien le concept de prix hédonique peut être complexe.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Deuxièmement, la valeur d'un petit bout de fonctionnalité peut souvent représenter la valeur totale du produit. Par exemple, quelle est la valeur de la roue avant-gauche d'une voiture ? Bien, étant donné que je ne souhaite pas avoir de voiture sans cette roue, la valeur de cette roue représente la valeur totale de la voiture.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Maintenant que nous avons identifié deux problèmes avec l'estimation de la "valeur métier" d'une user story, parlons du problème à déterminer le coût d'une story.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''Le problème du coût réparti'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Finalement, lorsque nous essayons de définir une valeur métier en points sur de petites fonctionnalités (comme les user stories), il y a le problème supplémentaire de déterminer le coût de la fonctionnalité. Il y a souvent le désir de calculer une sorte de retour sur investissement (ROI) des fonctionnalités, en comparant la valeur métier en points au coût de la story en points. Pourtant, avec de petites fonctionnalités, il apparaît souvent que le coût réel de l'implémentation d'une fonctionnalité est égal à la somme des coûts liés à l'implémentation de plusieurs petites parties du système, certaines d'entre elles (par exemple des travaux d'architecture) ne peuvent être estimées séparément.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Par exemple, le coût lié au remboursement d'un achat par carte de crédit devrait inclure certains travaux d'infrastructure d'abord liés à l'acceptation de la carte de crédit. Cependant, ce coût a probablement été estimé comme une partie de la story "acheter les articles qui composent mon panier". Le fait de ne pas réussir à répartir le coût de cette infrastructure de traitement de la carte de crédit entre les stories d'achat et de remboursement, peut mener à des décisions incorrectes en termes de ROI.</span><br /> <span style="display: block; text-align: justify">Comme pour le prix hédonique, cela fait des années que les économistes se battent avec ce sujet. Un exemple simple est l'élevage d'une vache et la vente de la viande bovine et du cuir. Comment devrait-on répartir le coût pour élever la vache entre les user stories "viande bovine" et "cuir" ? Nous pourrions dire que le coût concerne exclusivement la viande bovine et que le cuir est gratuit, mais ce serait incorrect, le contraire aussi d'ailleurs. Les bénéfices (viande bovine et cuir) doivent être considérés ensemble en les comparant au coût pour élever la vache.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''Que doit-on faire alors ?'''</span><br />  Cela veut-il dire que nous ne pouvons jamais affecter une valeur métier aux fonctionnalités et que nous devons renoncer à l'analyse du ROI des user stories ? Pas nécessairement. Mais ce type d'analyse s'applique beaucoup mieux au niveau des epics (grosses user stories) et des thèmes (groupe de stories), car la valeur et le coût peuvent être correctement envisagés à ces niveaux.<br /> <br />