Piloter l’agilité avec la vélocité

Je rencontre pas mal d’équipes Scrum qui se posent la question de l’utilité de l’estimation des stories en points !

Ok, me disent-ils, nous savons que les points permettent de calculer la vélocité (i.e.: la vitesse de l’équipe), c’est à dire le nombre de points par durée fixe de temps ou itération (comme des km/h pour une voiture), mais chez nous, personne n’utilise la vélocité pour prendre des décisions, du coup, à quoi ça sert d’estimer en points ?

Effectivement, vu sous cet angle, l’équipe aurait raison d’arrêter une pratique qui prend du temps et qui ne leur sert à rien, et pourtant, un Product Owner bien informé dispose avec la vélocité d’un outil réel de pilotage Agile.

Ce que je recommande de mettre en place sur tous les projets que j’accompagne est …… un Burndown Chart de Release qui fait apparaître la vélocité cumulée, la quantité de points restants dans le Product Backlog et la capacité restante basée sur la vélocité prévisionnelle de l’équipe sur les sprints à venir.

Parfois, il est également intéressant de faire apparaître un buffer en points qui n’est pas une réserve en cas de dérapage mais simplement une réserve de choses à faire qui n’ont pas encore été identifiée (il est tout à fait normal avec Scrum que l’équipe découvre des stories au fur et mesure de l’avancement du projet).

Le schéma ci-dessous donne une représentation de ce que pourrait être un Burndown Chart de Release.

Que nous apprend-il ?

• Cette release contient 6 itérations
• La vélocité prévisionnelle de l’équipe est de 40 sur les 3 premières itérations et de 20 sur les 3 suivantes (la diminution du nombre d’équipiers est planifiée), soit 180 au total

SPRINT 0

• A la fin du Sprint 0, les stories présentes dans le Backlog sont estimées à 153 points
• Le Product Owner a gardé un buffer de 27 points pour les stories non encore identifiées

SPRINT 1

• L’équipe réalise une vélocité de 32 points pour 40 attendu (c’est bien)
• L’indicateur de capacité restante (140) est dans la zone jaune (le buffer), ce qui indique qu’il ne sera pas possible de délivrer tout le backlog actuel (128) + le buffer (20)
• Il est urgent d’attendre … calmement !

SPRINT 2

• L’équipe réalise une vélocité de 42 points pour 40 attendu (c’est toujours bien … et non pas mieux comme certains l’ont pensé !)
• L’indicateur de capacité restante (100) est toujours dans le jaune … mais il reste encore 4 sprints … tout va bien … pas de sur réaction … restons zen

SPRINT 3

• L’équipe réalise une vélocité de 47 pour 40 attendu (c’est toujours bien … eh oui !)
• L’indicateur de capacité restante (60) est dans le orange … tout va bien … l’équipe devrait pouvoir implémenter tout le backlog et le buffer 🙂

SPRINT 4

• L’équipe réalise une vélocité de 26 pour 20 attendu (c’est bien … vous vous en doutiez, non ?)
• L’indicateur de capacité restante (40) est dans le orange … c’est cool !

SPRINT 5

• L’équipe réalise une vélocité de 16 pour 20 attendu (c’est bien … vous êtes d’accord)
• L’indicateur de capacité restante (20) est dans le orange … c’est parfait
• Le Product Owner décide de sécuriser sa Release et ne positionne que 13 points de stories à faire dans le 6ème et dernière itération … c’est une très bonne pratique !

SPRINT 6

• L’équipe réalise une vélocité de 13 pour 20 attendu (c’est bien … maintenant vous savez !)
• La Release est terminée en temps et en heure
• L’équipe en profite pour faire quelques stories techniques qui seront intégrées dans la Release suivante … et surtout pas celle en cours !!!

Bien entendu si l’indicateur de capacité restante est dans la zone grise à la fin de la 4ème itération … cela indique que le projet aura des difficultés à se terminer correctement. Il faudra donc prendre une décision et faire évoluer un des paramètres de la gestion de projet (le délai, le coût, le périmètre ou la qualité) en fonction du contexte du projet.

Et ce n’est qu’un exemple d’utilisation de la vélocité, il y en a d’autres que je vous détaillerais dans un article à venir.