S’il est un principe qui n’est pas facile à comprendre en démarrant une la méthode Scrum c’est le calcul de la vélocité.

Premièrement parce qu’il est abstrait, impalpable, virtuel ; si la vélocité d’un cycliste représente le nombre de tours de pédalier effectué par minute, la masse de travaille abattu par une développeur – ou une équipe – est bien plus difficile à démontrer, cela demande un grand travail d’abstraction.

Deuxièmement, la vélocité d’une équipe Scrum est maintenant mesurée en valeur relative (Story Point) au lieu des traditionnels nombre de jours ou nombre d’heures. Il s’agit d’un changement de paradigme, il faut donc réfléchir autrement et ça peut être difficile.

 

Ne comparez pas la vélocité de deux équipes

Une discussion entendue entre deux responsables de produit qui se rencontrent dans un forum m’a fait siffler les oreilles :

– Ton équipe elle fait combien de Story Point par Sprint ?
– 42 environs et toi ?
– 65
– Ah, purée ils sont bien meilleurs les tiens.

Cette discussion est sans fondement, premièrement car la valeur d’un story point pour l’équipe 1 et l’équipe 2 n’est pas identique. Si l’équipe 1 défini que a réalisation d’une user story X vaut 5, l’équipe 2 l’évaluera peut être à 8 : donc la même tâche n’aura pas la même valeur. Pire encore : l’équipe 1 réalisera peut-être sa User Story évaluée à 5 SP en 4 jours et l’équipe 2 la User Story à 8 SP en 3 jours. En résumé le rapport de la tâche au story point et du story point au temps n’est pas le même.

Deuxièmement, comment comparer le travail de deux équipes si elles sont sur des produits différents, avec peut-être des technologies et des contraintes différentes. Et quand est-il de la qualité? Est-ce la même livrée par les deux équipes? Et même si vous aviez deux équipes quasi identiques qui travaillent sur la même chose, êtes-vous certain de vouloir instaurer ce climat de compétitivité ? Mais c’est une autre discussion.

La vélocité ne doit uniquement se comparer que d’un sprint à l’autre avec la même équipe afin de suivre l’évolution.

 

 

 

Continuer de donner une valeur temporelle au Story Point

S’il est une chose à ne pas faire c’est de donner une valeur en temps (heures, jours) au story point au sein de l’équipe de développement qui réalise l’évaluation. Au début forcement vous trouvez cela pratique : une fonctionnalité X = Y heures = Z Story Points. Mais c’est une mauvaise pratique car vous allez masquer la progression (ou régression) de la performance de votre équipe.

Voici donc l’exemple de ce qu’il ne faut pas faire :

Si durant l’année 1 votre équipe estime et réalise une tâche « X » de la manière suivante :

Tache X = 16 heures = 8 SP

L’année 2, l’équipe estime et réalise la même tâche (elle est maintenant plus performante et peut réaliser cette même tache plus facilement) si vous calculez en heures voici ce qui va se passer :
Tache X = 10 heures = 5 SP

Donc au final l’année 2 pour le même travail l’équipe réalisera 5 story points au lieu de 8 et comblera les 3 story points manquant en prenant d’autres tâches. Elle sera donc hyper-performante par rapport à l’année 1 mais au final réalisera le même nombre de SP.

L’année 1, seule la tâche X était réalisé pour 8SP:

Tache X = 16 heures = 8 SP

L’année 2, les tâches X,Y,Z sont réalisées mais pour 8SP toujours:

Tache X = 10 heures = 5 SP
Tache Y = 4 heures = 2 SP
Tache Z = 2 heures = 1 SP

Performance de l’équipe stagnante (alors même qu’elle réalise plus de tâches):

Voici maintenant la véritable démarche :

L’année 1, seule la tâche X était réalisé pour 8SP :

Tache X = 8 SP

L’année 2, les tâches X,Y,Z sont réalisées mais la tâche « X » vaut toujours 8SP:

Tache X = 8 SP
Tache Y = 2 SP
Tache Z = 1 SP
(vraisemblablement les tâches Y et Z pourrait valoir aussi plus de SP sur le même principe, de même il devrait y avoir plus de sprints composés de nombreuses US, mais on ne va pas compliquer cet exemple)

Soit un total de 11 SP pour l’année 2 :

Cette fois l’amélioration de l’équipe est visible. Durant le premier exemple la performance de l’équipe disparaissait dans l’évaluation.

Un grand merci à Christian Lapointe de Pyxis Suisse pour son aide sur ce billet.