Vélocité, productivité et rock'n roll

Une autre vue sur l'estimation en points, sans la perplexité et la complexité.

Franck (@DirtyF) m'a demandé ce que je pensais de Perplexité, complexité, vélocité ...une autre vue. L'article est une réaction à Perplexité, complexité et vélocité de Christophe Thibaut. J'avais parcouru le billet original; l'histoire est vraiment très bien racontée mais le fond du message m'avait laissé ...perplexe.

Après sa lecture, Eric Daspet (@edasfr) a été aussi assailli par le doute. Je suis d'accord avec lui sur plusieurs points :

  1. sa réticence à estimer uniquement en fonction de la complexité fonctionnelle,
  2. l'oubli des estimations sur les travaux techniques,
  3. la confusion entre vélocité et productivité.

Sur le premier point, j'ai écrit il y a quelques moins qu'il valait mieux parler d'effort plutôt que de taille d'une story, justement pour éviter de se cantonner à la complexité fonctionnelle quand on estime. L'estimation en points porte sur de l'effort, comme le dit Mike Cohn : It's effort, not complexity.

Concernant les travaux techniques importants, je recommande depuis longtemps d'en faire des stories techniques, de les mettre dans le backlog et de les estimer comme les autres. Une story technique est une story dont les résultats ne sont pas visibles des utilisateurs, mais qui apporte de la valeur au produit.

A propos du dernier point, la vélocité n'est pas une mesure de productivité.

Cependant je ne suis pas tout à fait d'accord avec Eric sur l'objectif de la mesure de la vélocité et sur sa visibilité. Même si c'est vrai qu'elle peut devenir un enjeu politique, la vélocité ne doit pas être restreinte à l'équipe, la transparence pousse à la communiquer à l'extérieur.

Son objectif principal est de faire de la planification à moyen terme (avec le plan de release). Ce n'est pas de mesurer la productivité, nous l'avons vu, ce n'est pas non plus d'estimer ce qui sera réalisé pendant le sprint : la vélocité est une mesure, pas une estimation.


Sur le même sujet :