De la valeur à l'utilité

En préparant ma présentation Estimations, mesures et indicateurs agiles à l'Agile tour du 22, je revois la notion de valeur.

C’est un précepte de Scrum et des méthodes agiles : on cherche à maximiser la valeur ajoutée. Plus la valeur d’un élément est importante, plus sa priorité est élevée et, comme la priorité définit l’ordre dans lequel les éléments du backlog sont réalisés, les éléments avec le plus de valeur sont développés en premier.

Mais ce n’est pas facile d’estimer la valeur ajoutée par une story…

Il faut déjà définir ce qu’on entend par la valeur métier : le retour sur investissement, la valeur actuelle nette ? Ensuite, il faut un gros travail d’étude pour estimer la valeur financière que va rapporter un élément du backlog.

Personnellement je n’ai pas rencontré d’entreprises qui avaient défini la valeur en euros des fonctions d’un logiciel. De plus, la valeur est une notion mal comprise : on s’aperçoit que beaucoup la confondent avec le coût.

Pour éviter les confusions, il est préférable de changer de vocabulaire et de parler d’utilité.

C’est une notion utilisée en économie : l'utilité est une mesure du bien-être ou de la satisfaction obtenue par la consommation, ou du moins l’obtention, d’un bien ou d’un service. Elle a aussi l’avantage d’être plus générale : si tous les produits ne visent pas à apporter de la valeur financière, ils ont tous vocation à être utiles. C’est le cas des logiciels Open Source.

Utilité relative

De la même façon que l’estimation de la taille se fait en points sans unité, l’utilité s’estime de façon relative. Le Product Owner fait, implicitement, un tri selon l’utilité des stories quand il ordonne son backlog par priorité (c’est ce qu’on appelle l’utilité ordinale).
Pour aller plus loin que l’ordre et avoir une mesure, il faut évaluer l’utilité de chaque élément (faire de l’utilité cardinale). Il y a plusieurs techniques possibles, comme le Priority Poker.

Sur quels éléments du backlog estimer l’utilité

Des user stories peuvent être trop petites et sont nombreuses, c’est pourquoi, au départ, la pratique la plus simple est de définir l’utilité sur des features plutôt que sur des user stories, ce qui limite le nombre d’éléments à estimer.
Les autres types de stories, les stories techniques et les défauts, n’ont pas une utilité directe, perceptible par des utilisateurs. Cependant, comme des user stories en dépendent, il est possible de leur allouer une utilité indirecte.

Utilité et taille

La taille et l’utilité sont statistiquement corrélées : en moyenne, plus la taille est grande plus l’utilité est importante. Mais ce n’est évidemment pas vrai pour toutes les stories : on connait tous l’exemple de fonctions faciles à développer qui peuvent très utiles (ou inversement des « usines à gaz » inutilisables).

Il peut être intéressant, pour faire des mesures, qu’un élément du backlog possède deux attributs distincts : sa taille et son utilité.

Le ratio utilité sur taille (R = U/T) pourrait ainsi donner une idée du meilleur retour sur investissement (le fameux ROI !) et, plus concrètement, aider à définir les priorités dans le backlog. Mais pour y arriver le chemin est long et l’essentiel n’est pas de produire des mesures, essayons déjà de nous servir de l’utilité relative pour prioriser.

Voir aussi