La vélocité, un indicateur obligatoire en Scrum ?

Une question se pose souvent dans les équipes qui font du Scrum : la vélocité, un indicateur obligatoire en Scrum ? J’ai toujours été surpris de voir l’importance apporté à cet indicateur souvent peu utilisé.

Qu’est-ce la vélocité ?

Pour ceux qui ne connaisse pas la vélocité, je vais expliquer rapidement ce qu’est la vélocité ; mais ceux qui ne l’ont pas manipulé n’auront pour être honnête que peu d’intérêt de lire cet article.

La vélocité est un indicateur très utilisé en Scrum pour suivre le travail réalisé d’une équipe sur plusieurs sprints. La vélocité est utilisé en France pour parler de la somme totale du nombre de point d’effort total des demandes intégralement terminée en fin de sprint.

Ce terme est parfois discuté par certains agilistes qui considèrent que la vélocité doit être définit par l’accélération du nombre total de point d’effort d’un sprint au suivant (mais cette définition de la vélocité n’est pas utilisé en France). Cette article fera donc référence à la première définition de la vélocité.

Nous allons prendre un exemple simple pour comprendre. Voici l’état de 4 tickets en fermeture de Sprint :

• 1 ticket avec 3 en point d’effort en In progress
• 1 ticket avec 1 en point d’effort en Done
• 1 ticket avec 3 en point d’effort en Done
• 1 ticket avec 5 en point d’effort en Done

La vélocité du sprint qui se termine sera alors de 1+3+5 soit de 9. En effet c’est très simple à calculer.

Nous avions parlé de la vélocité en vidéo sur La Minute Agile, n’hésitez pas à la regarder.

A quoi sert la vélocité ?

Voici un exemple de graph de vélocité qui compare la vélocité sur laquelle l’équipe s’était engagée en début de sprint et la vélocité finalement réalisée en fin de sprint (graph venant du logiciel Jira).

On peut aussi comparer les vélocités entre elles en comparant les courbes vertes. Cela a pour but de voir l’évolution du travail de l’équipe voire de faire de la prédictibilité.

Malheureusement car je ne suis pas coutumier de ces pratiques (pour ne pas dire opposé), ces indicateurs de vélocités centraliséés sur un outil permettent dans certaines entreprises de réaliser des comparaisons entre projet voire pour déclencher des plans actions.

Stop aux utilisations détournées

Attendre une évolution (montante) constante de la vélocité

Certaines entreprises attendent que chaque équipe améliore constamment sa vélocité d’un sprint à l’autre.

Il n’est pas rare que la vélocité des 3 premiers sprints soit en réelle progression pour plusieurs raisons :

• L’équipe apprend à se connaitre
• Le sprint 0 (ou création du socle technique) est souvent perturbant au démarrage d’un projet

Mais au bout de 4 sprints, il est rare que comparer la vélocité d’un sprint à l’autre soit pertinent. Il arrive quelques fois dans les grands groupes que le projet soit totalement bloqué par des éléments extérieurs mais cela reste une toute petite minorité des cas.

Ceux qui ne mettent pas de complexité aux bugs peuvent en effet voir un intérêt de comparer les vélocités car elles sont légèrement liées à la valeur business.

Article : Scrum : Met-on de la complexité sur les bugs ?

Cependant, décider de remettre en cause l’équipe en cas de baisse de vélocité n’a aucun sens car de nombreuses choses peuvent la baisser :

• le point d’effort n’est pas une estimation parfaite
• l’équipe est touchée par une grippe
• un séminaire a eu lieu
• un changement de leader d’une équipe (qui peut influer sur les points d’effort)
• l’incrément de petits correctifs (design, ajustement de textes,…) minuscules qui additionnés ont tendances à augmenter artificiellement la vélocité en cours de projet à des moments plus stratégiques (plein de petites US très rapides).

Il existe de nombreux cas qui peuvent indiquer qu’une baisse de vélocité n’apporte aucune information intéressante. D’ailleurs celle-ci n’indique pas forcément une baisse de productivité.

Dans ce cas et si l’entreprise est très « indicateur », je préfère encore faire une courbe de productivité qui a plus de sens car elle prend en compte une notion de temps.

La comparaison d’une vélocité d’un projet à un autre : un non sens

Malheureusement, on voit encore des entreprises comparer la vélocité d’une équipe à l’autre. Bien évidemment cette pratique fini par se savoir et ne peut qu’apporter des problèmes si l’équipe se sent dans l’obligation de devoir prouver quelque chose (parfois par prime alléchante à la clé).

On voit parfois des équipes qui finissent par sur-estimer les demandes en pensant qu’elles s’alignent aux autres présentées comme plus productives. Je vous laisse imaginer l’intérêt d’avoir ce type de pratiques au sein des entreprises.

Il est fort probable que la vélocité finisse par augmenter alors que la productivité est en pleine baisse.

Pourquoi la vélocité est rarement utile ?

Quand je regarde la mise en place du Scrum dans de nombreuses équipes, je vois beaucoup d’équipes faire de l’estimation sans but réel :

• j’estime pour avoir une vélocité
• ma vélocité me sert à …… rien

Si vous ne faites pas un vrai calcul de prédictibilité ou que votre vélocité vous permet de faire des comparaisons inutiles, je vous conseille de sortir de ce cadre qui ne vous fait en fait que perdre du temps.

Profitons du temps que nous avons pour l’offrir réellement à la productivité des équipes.

Maintenir des courbes de vélocité, estimer des tâches (je parle vraiment de la partie point et pas de la discussion autour des demandes qui restent toujours très utile), le maintient de jolis graphs liés à la vélocité sur les murs sont des pertes de temps si la vélocité n’est pas utilisée.

Voici une vidéo sur La Minute Agile autour de ce sujet :

Conclusion

Même si cela peut paraître obligatoire, la vélocité est un indicateur à utiliser que si il vous sert vraiment. Analysez bien la situation de vos équipes et vérifiez que cette « vélocité » ait vraiment un sens.

L’utilisez-vous vraiment ou suivez-vous la seulement par principe ?