La vélocité n'est pas une mesure de productivité

La vélocité est une mesure typique des méthodes agiles. Elle ne doit pas être confondue avec la productivité

La vélocité ne doit pas être confondue avec la productivité. Ce sont deux mesures différentes, contrairement à des idées répandues. Il arrive même qu'une augmentation de la vélocité aille de pair avec une diminution de la productivité.

La vélocité est la mesure du nombre de points finis pendant une itération. Elle donne une indication de la capacité de l'équipe.
Quand elle est utilisée à bon escient, la mesure de la vélocité permet à l'équipe :

  1. de s'engager sur le court terme (contenu d'une itération)
  2. de prévoir sur le moyen terme (planning de release)

Pour le point 1, l'idée est de se baser sur la mesure concrète de la vélocité pour en déduire la capacité pour la prochaine itération. Ce n'est qu'une indication, car lors de la réunion de planification de l'itération, le périmètre est plus défini par l'engagement de l'équipe sur ce qu'elle estime pouvoir faire que par un total de points égal à la vélocité passée[1]

Pour le point 2, le calcul de la vélocité concourt à la production du beurdone de release. Cependant le reste à faire utilisé dans le beurdone dépend aussi des variations de périmètre. Comme le montre l'article que je cite plus haut, ce n'est pas parce que l'équipe a une vélocité qui augmente que le reste à faire diminue, en particulier si de nombreux bugs viennent s'ajouter dans le backlog.

La définition classique de la productivité, c'est le résultat / le temps passé à produire. C'est surtout utilisé en économie pour montrer que l'utilisation de machines permet de réduire le temps de production.
Encore quelques remarques pour différencier vélocité de productivité :

  • La vélocité est basée sur les estimations en points. Et malheureusement, si la vélocité augmente, il n'y a pas moyen de savoir si c'est dû à une amélioration de la productivité ou à des mauvaises estimations.
  • Il est aussi possible augmenter artificiellement la vélocité, j'ai connu un chef de projet qui n'avait pas encore l'esprit de ScrumMaster pousser à des ré-estimations en hausse avant chaque sprint parce qu'il croyait malin d'afficher une vélocité qui augmente, en rejetant sur le Product Owner l'augmentation du nombre de points à faire au total.
  • L'estimation en points a un rapport avec le coût de développement, et donc la vélocité aussi. La définition de la productivité parle de résultat. A mon avis, ce n'est pas le coût qu'il faudrait utiliser[2] mais la valeur apportée.
  • La valeur n'est pas forcément exprimée en unités monétaires, elle peut aussi être évaluée de façon relative en sorte de point de valeur, comme on le fait avec le priority poker. La mesure de la valeur apportée par chaque itération, faite de cette façon, se rapprocherait plus de la productivité au sens utilisé en économie[3].
  • La vélocité est une mesure de l'équipe, pas de personnes individuelles.

Notes

[1] Il faut éviter la tendance, que j'ai eu moi aussi au début, qui consiste à tabler sur une croissance régulière de vélocité

[2] on fait la même erreur, en pire, quand on parle de productivité pour le nombre de lignes de code écrites par jour

[3] mais si la valeur est relative, elle ne pourrait pas être comparée entre plusieurs projets