Arrêtons de vouloir suivre la productivité d’une équipe Agile par sa vélocité !

La vélocité peut être un indicateur précieux pour suivre le travail réalisé par une équipe Agile (Scrum) lors d’un sprint et aider à la prédictibilité du suivant. Par contre vouloir utiliser cette métrique comme indicateur de mesure de la performance ou d’amélioration de la productivité d’une équipe est loin d’être une bonne idée. Cette idée est pourtant très répandue dans certaines entreprises.

Qui n’a pas déjà été confronté à la volonté (des managers notamment) :

-         D’utiliser la vélocité pour mettre en concurrence, comparer les équipes : Pourquoi l’équipe A a-t-elle une vélocité de 150 alors que la B a une vélocité de 200 ?

-         De rechercher l’augmentation systématique de la vélocité sprint après sprint : Pourquoi votre vélocité n’augmente-t-elle pas ? Vous aviez une vélocité de 150 lors du dernier sprint pourquoi ne pas faire 200 pour le prochain sprint ?

Qu’est-ce que la vélocité et comment la calcule-ton ?

La vélocité est un indicateur très utilisé en Scrum pour suivre le travail réalisé d’une équipe Agile sur plusieurs itérations (sprints). Elle correspond à la somme des points d’effort effectué par l’équipe pour terminer les User Stories (US) dans un sprint. Elle se calcule donc a posteriori.

Au démarrage du 1er sprint, l’équipe estime, le plus souvent en points, l’effort qui lui sera nécessaire pour terminer (conformément aux critères dits DOD, « Definition Of Done », concernant le développement, les tests …) les User stories (US) souhaitées par le Product Owner (PO).

Exemple:

Soit un total de 40 points.

Cette estimation est comparée à la capacité de l’équipe, c’est-à-dire la disponibilité de l’ensemble de ses membres, également calculée en points. Cette capacité prend en compte les vacances, les formations et autres événements ou activités qui rendraient l’équipe indisponible pour travailler à la réalisation des User Stories.

Dans notre exemple, la capacité de l’équipe est de 42 points pour le sprint. Il s’agit de son estimation de vélocité.

L’estimation totale pour terminer les US étant inférieure à la capacité de l’équipe, le contenu du sprint est validé. L’équipe se lance dans la réalisation des US.

En fin de sprint 1, l’équipe additionne les points de l’ensemble des US réellement terminées lors du sprint. Elle dispose ainsi de sa 1ère mesure de vélocité.

Dans notre exemple, l’US 1 de 3 points d’effort n’a pas été terminée. La vélocité réelle de l’équipe est donc de (40-3) 37 points.

Itération après itération, l’équipe calcule sa vélocité et améliore petit à petit la fiabilité de la valeur de sa vélocité moyenne.

Pour notre exemple, voici un graphique qui compare la vélocité estimée sur laquelle l’équipe s’était engagée en début de sprint et la vélocité finalement réalisée, identifiée fin de sprint :

Il faut attendre 3 à 5 itérations pour obtenir une image fiable de la vélocité moyenne de l’équipe. Le 1er sprint est généralement complexe, les membres d’équipe ne se connaissent pas ou peu, ne maîtrisent pas les processus et découvrent le périmètre fonctionnel. Leur vélocité est donc rarement très élevée. Elle va augmenter progressivement jusqu’à se stabiliser. La vélocité est alors représentative, même si elle reste une estimation, de l’effort qu’est capable de produire l’équipe durant un sprint.

Bien plus que la progression de la vélocité sprint après sprint, c’est la stabilité de la vélocité qui est recherchée pour favoriser l’engagement à court terme de l’équipe :

-         La vélocité moyenne permet ainsi de prévoir assez fidèlement le nombre de points d’effort que pourra réaliser l’équipe, et donc d’optimiser la sélection des US à réaliser, durant le prochain sprint.

-         Le suivi de sa vélocité permet à l’équipe de s’engager plus sereinement sur le nombre de points à développer lors du prochain sprint.

Dans notre exemple :

La vélocité moyenne sur les 3 derniers sprints étant de 56,7, l’équipe peut s’engager à mettre en œuvre des User Stories pour un total de 56 points d’effort.

Cette stabilité, de plus, favorise la prédictibilité moyen/long terme :

-         Elle détermine la tenue des délais, et aide à mieux maîtriser leur gestion, sur un sous ensemble de fonctionnalités indispensables (ou MVP, « Minimum Viable Produit »), une release, un produit.

-         Associée à une estimation du Backlog de produit, la vélocité permet d’identifier le nombre de sprints nécessaires pour réaliser le périmètre souhaité, et d’effectuer des arbitrages, si besoin.

Dans notre exemple :

La vélocité moyenne sur les 3 derniers sprints étant de 56,7, l’équipe peut en déduire qu’il lui reste encore 5 sprints pour réaliser le périmètre souhaité. Cette projection sera affinée au fur et à mesure de l’avancement.

De la bonne utilisation de cette métrique…

La vélocité est donc propre à une équipe. Elle est fondée sur ses propres éléments de référence et est fonction de son environnement de travail : taille d’équipe, expertise technique, maturité agile, domaine fonctionnel…

Comparer la vélocité de 2 équipes n’a pas de sens, ne permet aucune conclusion. De plus l’équipe ayant une vélocité inférieure pourrait avoir l’impression de devoir faire ses preuves, et ainsi vouloir l’augmenter artificiellement (en surestimant l’effort de réalisation des US par exemple). On aurait ainsi des vélocités qui augmentent, mais avec une performance, une productivité (en réalité) décroissante.

A noter, la vélocité concerne l’équipe entière, il ne s’agit surtout pas d’utiliser une notion de vélocité individuelle pour challenger les membres de l’équipe entre eux.

La vélocité est un outil efficace pour valider le contenu d’un sprint ou au contraire revoir sa planification, mais en aucun cas il ne faut l’interpréter comme un indicateur de performance. Une vélocité augmentant n’est pas forcément signe d’une meilleure performance de l’équipe.

Au démarrage d’un nouveau projet, la vélocité peut augmenter ou diminuer et c’est normal. L’équipe apprend à se connaitre et cherche la meilleure façon de travailler et collaborer ensemble. Mais il est tout aussi normal qu’ensuite la vélocité de l’équipe reste stable, en conditions identiques : mêmes membres d’équipe, hors vacances …

Après quelques sprints, la vélocité se stabilise donnant un indicateur de prédictibilité pour l’équipe. Chercher à l’augmenter à tout prix risque de se faire au détriment de la qualité des fonctionnalités livrées. Il y a également risque d’introduire un rythme de travail de moins en moins soutenable, et finalement, de démotiver l’équipe.

Pour finir, une diminution de la vélocité peut intervenir en fonction de la vie de l’équipe (des développeurs malades, une formation, un changement d’équipier ou de Scrum Master…) sans que cette baisse n’indique une véritable baisse de productivité.

Chercher à suivre l’amélioration de la productivité de l’équipe par l’augmentation de sa vélocité s’avère donc inutile. 

Quelles métriques utiliser pour suivre la productivité d’une équipe Agile ?

La productivité d’une équipe Agile peut être définie comme la quantité de valeur apportée à l’utilisateur final, le client, dans un intervalle de temps (un sprint par exemple pour une équipe Scrum).

Augmenter la productivité, la performance, de l’équipe revient à produire plus de valeur dans le même temps ou à produire autant de valeur mais dans un temps plus court.

Attention, suivre la productivité de l’équipe ne consiste pas à suivre le nombre d’US produites dans une itération. (Tout comme il ne s’agit pas de suivre le nombre de lignes de code écrites).

Une équipe peut développer un nombre considérable d’User Stories mais si elle travaille sur les mauvaises fonctionnalités, les utilisateurs n’en auront que faire.

Il est important de noter que la valeur, des fonctionnalités du Produit, évaluée par le PO n’est qu’une spéculation. La seule façon de mesurer réellement si ce qui est développé a de la valeur c’est de mesurer la valeur une fois le logiciel entre les mains des utilisateurs. Seuls ces derniers peuvent dire si les fonctionnalités du produit ont de la valeur.

La productivité d’une équipe peut donc être déterminée par :

-         Le développement de fonctionnalités (via les US) à forte valeur attendue pour les utilisateurs

-         Leur mise à disposition rapide à ces mêmes utilisateurs.

Ces nouvelles fonctionnalités devant être, bien sûr, de bonne qualité (faible taux d’anomalies).

Voici donc quelques métriques possibles pour suivre l’évolution de la productivité d’une équipe Agile.

Suivi de la valeur du produit :

-         Somme de la valeur qu’il est prévu de livrer versus somme de la valeur effectivement livrée

-         Nombre de User Stories planifiées versus nombre d’US effectivement terminées.

Il peut être intéressant également de suivre un indicateur de prédictibilité des engagements de l’équipe.

Suivi de la qualité du produit :

-         % de couverture des tests unitaires

-         Nombre de défauts

-         Nombre de cas de tests.

Il peut également être intéressant de suivre le nombre de cas de tests automatisés

-         Nombre total de tests

Avec pourquoi pas le % de tests automatisés

-         Nombre de refactoring (pour diminution de la dette technique)

-         Nombre de rollbacks effectués

-         Dates des rollbacks effectués versus dates de mise en production (pour déterminer s’il existe une relation entre les deux).

Suivi du flux de mise à disposition des fonctionnalités :

-         Nombre de déploiements

-         Délai de mise à disposition des fonctionnalités

On retrouvera ici des indicateurs concernant le workflow de mise à disposition d’une nouvelle fonctionnalité (et ce, de son émission à sa mise à disposition pour les utilisateurs), avec mise en lumière : des temps d’attente et de la quantité de travail de l’équipe dans les différentes phases du flux.

Et vous quelles métriques utilisez-vous pour suivre la performance de vos équipes Agile ?