La vélocité, une mesure fausse!

Après 9 mois comme Scrum Master auprès de son équipe, mon client me dit un jour : « L’équipe ne s’améliore pas, la vélocité moyenne n’a pas bougé depuis plusieurs mois! Que penses-tu faire? »

Ma réponse : « Rien! »

Cette remarque nous a permis d’entamer une conversation sur ce qu’est la vélocité. À qui et à quoi sert-elle?

En Scrum, on appelle **vélocité** le nombre de points d’effort « terminés » au cours d’un sprint (et « terminé » dépend de la définition décidée par l’équipe).

Il s’agit d’un indicateur qui a pour but d’aider l’équipe de développement lors des séances de planification de sprint (« sprint planning ») à évaluer la quantité de travail qu’elle peut sélectionner pour le sprint. Cet indicateur peut être utilisé par le Product Owner pour l’aider à planifier les livraisons, et ce, à condition de prendre en compte le cône d’incertitude associé.

**La vélocité n’est ni une mesure de performance de l’équipe ni une mesure d’amélioration ou de productivité. Ce n’est PAS un indicateur pour la direction.**

Un premier élément à prendre en compte : l’estimation est relative, la vélocité l’est tout autant.

Le cerveau humain est absolument incapable d’estimer le temps, la distance ou la vitesse de façon absolue. Par contre, nous sommes très bons pour comparer. C’est la raison fondamentale pour laquelle nous évaluons les « Product Backlog Items » (ou PBI) de façon relative. Lors de l’évaluation, la taille (ou l’effort) d’un PBI est comparée à celle des PBI existants. Pour faciliter l’utilisation de ces évaluations, l’équipe leur attribue un nombre de points relatifs sur une échelle non linéaire (la suite de Fibonacci, par exemple).

L’important ici est que ces points sont relatifs et sans unité. Vous comprendrez alors que lorsque l’on presse une équipe à augmenter sa vélocité, elle n’a qu’à allouer un nombre de points plus grand à une taille donnée et le tour est joué. Du point de vue de l’utilisateur, rien n’a cependant changé.

Un second élément à prendre en compte : livrer de la valeur plus tôt est la chose qui importe le plus.

Votre équipe peut bien avoir une vélocité phénoménale, si elle travaille sur les mauvaises fonctionnalités, vos utilisateurs n’en auront que faire. D’ailleurs, il est important de garder à l’esprit que dans votre carnet de produit, la valeur évaluée par le PO n’est qu’une spéculation. La seule façon de mesurer si vous livrez de la valeur est de la mesurer une fois le logiciel entre les mains des utilisateurs. Seuls ces derniers pourront vous dire si vos fonctionnalités ont de la valeur. Encore faut-il la mesurer, et ce n’est pas chose aisée.

Dans le cas de la conversation amorcée avec mon client, je l’ai interrogé sur les différentes améliorations qu’il a notées ou perçues.

Très vite, il est devenu évident que la satisfaction des « clients » est bien meilleure, que la prévision de l’équipe (« forecast ») est plus fiable lors des séances de planification de sprint, que le temps de cycle minimum d’un PBI est passé de 7 semaines à 3 semaines, que les demandes de soutien ont diminuées, ce qui donne plus de place au développement de nouvelles améliorations, que le nombre de rectifications après livraison a sensiblement baissé, que 3 équipes se synchronisent pour livrer un incrément potentiellement livrable toutes les 2 semaines (passant au cours de la période de 1 à 2, puis à 3 équipes), que la définition de « terminé » (« definition of done ») s’est peaufinée, que l’autonomie et l’auto-organisation de l’équipe sont perceptiblement meilleures, etc.

Finalement, alors que la vélocité de l’équipe est demeurée stable, nous avons travaillé sur des sujets de fond dans le but d’améliorer la qualité, la vitesse de livraison et la valeur des items livrés. Un autre élément important, grâce à l’appropriation du carnet par l’équipe, la charge de travail du PO a été soulagée. Il demeure le propriétaire du carnet de produit (« product backlog »). Il continue d’en assurer l’intégrité et de l’ordonner afin de maximiser la valeur livrée. Toutefois, une fois le besoin partagé avec l’équipe, celle-ci prend pleinement et collectivement en charge le raffinement des PBI. Le PO donc peut maintenant se concentrer sur le reste des tâches qui lui sont dévolues.

**L’équipe s’est améliorée, encore faut-il regarder le bon indicateur.**

Au cours de la conversation, mon client a aussi compris tout l’intérêt qu’il peut y avoir à planifier lorsque la vélocité est stable et lorsque l’équipe est pleinement impliquée dans le raffinement du « product backlog ». En effet, cela lui permet d’avoir une projection « réaliste » de la date de réalisation et de mise en production des PBI et ainsi de faire les choix qui s’imposent pour ordonner son carnet de produit.

Pour finir, lorsque l’équipe comprend qu’elle ne sera pas évaluée en fonction de sa vélocité, mais bien selon la valeur livrée, la dynamique change pour sortir de la « course aux points » et se concentrer sur l’accroissement de la valeur livrée. L’équipe arrête aussi les conversations sur le fait de [réévaluer ou non un PBI non terminé] qui retourne dans le carnet de produit à la fin d’un sprint. Cela devient « normal », il n’y a plus aucun sentiment de « perdre des points » (différence entre l’estimation initiale et la réestimation du reste à faire sur un PBI non terminé). C’est la même chose qui se passe lorsque vous arrêtez de comparer des équipes en fonction de leur vélocité respective.

Ce n’est pas parce que la vélocité est un chiffre très facile à mesurer qu’il est pertinent.

Dans votre organisation, comment la notion de vélocité est-elle utilisée?