Quelle valeur pour la valeur ?

Pas facile de donner une valeur à la valeur ajoutée par une user story...

Dans la première version d'IceScrum, il y avait un attribut associé aux éléments du backlog de produit, qui s'appelait valeur. Je l'avais demandé parce que c'est un précepte de Scrum et des méthodes agiles que de définir la priorité en fonction de la valeur. Plus la valeur est grande, plus la priorité est importante et la priorité définit l'ordre dans lequel les éléments du backlog sont réalisés. A l'usage cet attribut a disparu : la priorité est simplement définie par le product owner sans attribut explicite[1].

C'est que donner une valeur à la valeur n'est pas chose facile. Il y a 2 difficultés :

  • il faut un gros travail d'étude pour estimer la valeur financière que va rapporter un élément du backlog. Il faut déjà définir ce qu'on entend par la valeur métier : le retour sur investissement, la valeur actuelle nette ? Personnellement je n'ai pas rencontré d'entreprises qui avaient défini la valeur des fonctions d'un logiciel.
  • des éléments du backlog peuvent être trop petits pour apporter de la valeur par eux-mêmes.

Un autre problème est que la valeur n'est pas le seul critère à prendre en compte pour définir la priorité. Luke Hohmann le montre très bien dans Why Prioritizing Your Product Backlog for ROI Doesn’t Work.

C'est pour ces raisons que la pratique la plus simple pour la priorité est de définir la valeur de façon relative plutôt qu'absolue et de le faire sur des thèmes ou des features plutôt que sur des user stories, ce qui limite le nombre d'éléments à ordonner. Au début d'un nouveau projet, un travail en groupe sous forme d'atelier impliquant les différents intervenants permet d'obtenir un backlog ordonné par priorité en quelques heures. Il y a plusieurs techniques possibles, comme le Theme scoring ou le Priority Poker.

Pour s'entraîner, on dispose maintenant d'une simulation avec le Business Value Game qui vient de sortir. Je vais l'essayer et, si le test est un succès, je l'inclurai dans mes cours.

Notes

[1] dans IceScrum c'est par glisser-déplacer entre les éléments du backlog qu'on change les priorités

Commentaires

1. Le jeudi 21 août 2008, 09:10 par Samuel

Comment aussi donner une valeur aux obligations légales qui n'apportent aucune valeurs sur le plan business ?

2. Le jeudi 21 août 2008, 09:53 par claude aubry

Samuel, il faudrait un exemple de ce que tu appelles une obligation légale pour être sûr que ça devient un élément du backlog. En imaginant que c'est le cas, on pourrait lui donner la valeur de ce que ça coûte de ne pas l'avoir, par exemple le montant de la pénalité. On peut aussi se poser la question de l'intérêt de passer du temps à chercher la valeur financière d'une obligation légale sachant qu'il y a d'autres attributs qui servent à définir la priorité, comme le risque.

3. Le mardi 26 août 2008, 12:02 par Samuel

Dans le cas d'un ancien projet, le logiciel devrait réaliser un envoi de données a un organisme pour consolider des stats au niveau national.

Aucun intéret pour le metier de mes clients, mais l'envoi de ces données était pourtant a leur charge.

Mais comme tu le dis, le risque est une facon de priorisé, c'est d'ailleurs ce qui a était fait