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.

Commentaires

1. Le jeudi 15 octobre 2009, 09:15 par pablo pernot

Je reste circonspect. Pour ma part vous jouez ici véritablement sur les mots, au sens propre.
Je reste circonspect car -au contraire- il me semble plus simple d'exprimer cette notion avec le mot valeur plutôt que celui d'utilité. Il y a plein de choses qui pourraient être utiles sur un projet mais qui ne sont pas forcément nécessaires, ni qui finalement n'apporterons de la valeur. Je suis d'accord avec le fait qu'il est très important que chaque membre de l'équipe s'approprie la valeur de chaque story comme si il était le product owner lui-même. C'est là que réside (très) souvent la difficulté. Le mot "utilité" renvoie à un sens trop immédiat, c'est utile parce que cela ou cela (liaison directe). Le mot utile fait aussi trop écho au mot outil : tiens cela serait utile d'utiliser telle ou telle chose. L'utile c'est plus le moyen, la valeur c'est la cible. Le mot valeur est peut-être un peu complexe à appréhender (je crois comprendre que c'est la théorie que vous défendez, donc vous proposer quelque chose de plus accessible), mais il décrit bien mieux la réalité. Je suis très sensible aux mots, je suis un afficionado des maximes du genre "ce qui se conçoit bien, s'exprime bien". Avec beaucoup de précautions je dirais que c'est une phase importante qui se déroule actuellement autour de l'agilité et de mon métier (conseil/informatique). Les concepts se matérialisent, on leur donne des noms, des mots. Ces mots sont très importants. Je reste donc circonspect avec celui d'utilité en remplacement de valeur. Mais je vais le tester (cela ne sera pas la première fois que je me tromperais).

ps : sinon côté rock'n roll j'écoute en ce moment beaucoup ZZTOP, ils ont sortis ma foi un très bon live dvd (Texas 2009), et comme leur prochain album se fera avec Rick Rubin on peut espérer une ressurection (comme Cash !). Du coup Deguello & Tres Hombres en boucle...

2. Le lundi 19 octobre 2009, 16:56 par Alix

La définition de "Valeur" dans le référenciel "ITIL" est :
Valeur = Utilité + Garantie.

Il est ici question de service mais dans le contexte SCRUM parle t'on uniquement de la valeur du produit ?

3. Le mardi 20 octobre 2009, 13:41 par claude

@pablo : l'intérêt de l'utilité, c'est de pousser à des estimations relatives, par analogie à l'estimation de la taille en points. Car j'ai écrit cela dans l'optique de faire des mesures et de produire des indicateurs. Pour le rock'n roll, je ne suis pas très fan de ZZ Top, mais je vais écouter cet album quand même pour voir.

@alix : ah, ITIL !  La garantie me fait penser à la correction des défauts qu'on peut constater sur une story. En fait si une story (ou feature) a une utilité de 10, la présence d'un défaut constaté alors que la story est finie (et utilisée) enlève de l'utilité, de 1 à 10 selon la gravité du défaut. En résumé, la correction du défaut rapporte donc de l'utilité et l'utilité de la story n'est pas acquise (on pensait que c'était 10, mais en fait c'était moins à cause du défaut).

4. Le mardi 20 octobre 2009, 20:59 par pablo pernot

Lequel Deguello ou Tres Hombres ? n'importe lequel des deux en fait...mais surtout Deguello. Et puis Free, Budgie, etc. On en parle vendredi à Montpellier

5. Le vendredi 23 octobre 2009, 12:29 par Alix

Ok pour mettre en regard les défauts et les stories mais alors là il me vient des questions :L'utilité finale d'une story est donc connue après son implémentation et sa qualification => quel est l'apport pour le projet de connaitre l'évaluation de de l'utilité d'un story une fois qu'elle est finie alors que c'est un élément de décision a priori ? Quel est le critère qui va être capitalisé ? et combien d'effort le projet doit il investir à suivre cet indicateur (est ce bien nécessaire) ?

ah, vous n'étiez pas à ma présentation jeudi ! L'utilité est une estimation, donc faite avant que la story ne soit réalisée (mesurer l'utilité réelle d'une story en production serait intéressant aussi mais c'est autre chose). L'objectif des méthodes agiles étant de maximiser l'utilité (la valeur), cela devrait être l'indicateur le plus important.
6. Le lundi 02 novembre 2009, 09:42 par Alix

Je suis bien d'accord, d'où ma question. Si la garantie fait partie de la définition de la valeur alors on ne connait la valeur réelle qu'à posteriori...