Scroll to top

Qu’est-ce que la vélocité ?

Qu'est-ce que la vélocité ?

La vélocité agile est un KPI de l’effort de travail réalisé par l’équipe de développement lors d’un sprint.

Une vélocité stable permet de prédire le contenu des itérations à venir. C’est un outil dédié à l’équipe Scrum et utilisé par le Product Owner pour définir sa roadmap.

Le suivi de la vélocité permet donc de voir l’historique des sprints finis mais aussi de prévoir les sprints à venir.

Comment calculer la vélocité ?

Le Product Owner maintient au quotidien le Backlog et la priorisation des tâches (US, technique, bugs, etc).

Tableau Kanban

Tableau kanban représentant le passage d’une tâche du backlog dans le sprint

 

A la planification de sprint, l’équipe scrum passe en revue les tâches « ready » du backlog par ordre de priorité. L’équipe de développement (et seule l’équipe de développement) s’engage sur une certaine charge de travail considérée comme réalisable en 1 sprint.

A l’aide du poker planning, chaque story intégrant le sprint est estimée en points (suite de fibonnacci, taille de T-shirt, etc) et pas en jour/homme ! Ce sujet épineux sera abordé dans un article à venir …

 

L’estimation prend en compte : la complexité, l’effort nécessaire et l’inconnu/le risque.

PokerPlanning

A la fin du sprint, l’équipe additionne les points des tâches finies. Seules les tâches terminées (voir la DoD) sont comptabilisées dans la vélocité du sprint.

Par exemple : A la planification de sprint, l’équipe s’est engagée sur une story à 3 points, une story à 5 points, deux stories à 2 points et trois stories à 1 point.

La vélocité estimée est donc de : 3 + 5 + 2 + 2 + 1 + 1 +1 = 15.

 

TableauKanban-Done

Tableau Kanban à la fin d’un sprint

 

A la fin du sprint, la story à 3 points n’est pas terminée, la vélocité sera donc de :

5 + 2 + 2 + 1 + 1 +1 = 12.

Après quelques premiers sprints, la vélocité de l’équipe est calculée en faisant la moyenne de la vélocité des sprints passés.

 

Par exemple :

KPI - Vélocité

La vélocité moyenne de l’équipe est de : (12 + 15 + 13 + 15 + 17) / 5 = 14

 

Pour une même équipe, la vélocité va d’abord tendre à augmenter sprint après sprint puis progressivement se stabiliser.
La stabilisation de la vélocité permet d’avoir des prédictions de plus en plus précises.

Comment représenter la vélocité ?

Plusieurs graphes peuvent être utilisés pour représenter la vélocité de l’équipe :

 

Vélocité partagée selon le type de tâches : ce graphe permet de voir l’évolution de la vélocité de l’équipe et avoir le détail sur le type de tâches finies par sprint (US, technique, bugs, etc);

Graphe vélocite selon type de tâches

 

Cumuler burnup chart : ce graphe permet de voir sur quel type de tâches les efforts sont concentrés.

Graphe vélocité cumulée

Comment utiliser ce KPI ?

La vélocité est un outil prédictif fiable : il permet au Product Owner de définir en avance le contenu des sprints à venir.

Prévisions sprints

Si le backlog est estimé et que la vélocité est stable, le Product Owner est capable d’estimer le nombre de sprint nécessaire à la réalisation d’une epic/d’un produit.

Plus la vélocité de l’équipe est stable, plus les prédictions des dates de fin vont s’avérer exactes.

Afin de mettre toutes ces données en lumière, le Product Owner peut utiliser le Burndown Chart de Release.

Ce graphe permet de visualiser :

La vélocité prévisionnelle de l’équipe
L’estimation du backlog
La vélocité cumulée

A partir de ce graphe, on peut voir le nombre de sprint prévu en se basant sur la vélocité prévisionnelle.

Graphe nombre de sprints prévus
Burndown chart de release. Backlog en gris; Réalisé en vert; Vélocité de l’équipe en bleu

De plus, dès lors que la courbe de vélocité passe en dessous de la barre représentant le backlog, les délais sont mis en péril. Cette donnée peut permettre de prendre des décisions assez en amont afin de terminer le projet à temps et avec qualité.

Les obstacles à considérer

Obstacles

La vélocité est un outil dédié à l’équipe scrum, ce n’est pas un indicateur de performance.

La vélocité peut descendre lors d’un sprint pour plusieurs raisons :

Mauvaise estimation lors du planning poker
Absence : maladie, urgence, congé, etc
Stories différentes : front, back, test, ux/ui
Stories pas clair, engagement pas réel
Changement de technologie
Turnover

Les erreurs à éviter

Estimation

Sous-évaluer les stories en planification de sprint pour ne pas diminuer la vélocité de l’équipe : « Nous n’avons pas pris assez de tickets. La vélocité de ce sprint est de 23, alors qu’on est capable de 25. Il faut ajouter une tâche de plus ».
L’équipe risque d’estimer la prochaine tâche à 2 alors qu’ils pensent qu’elle en vaut 5.

Sur-évaluer les stories en planification de sprint pour atteindre une vélocité fixée : « Encore une fois, nous n’avons pas atteint la vélocité estimée à la planification ».
L’équipe risque de sur-estimer les tâches afin d’être sûr de toutes les terminer dans le sprint, quitte à manquer de tâches.

Considérer que la vélocité est un indicateur de performance et présenter ce KPI aux stakeholders.

La vélocité n’entre pas en jeu lors de la planification de sprint. L’équipe s’engage uniquement sur la quantité de travail considérée comme réalisable. L’équipe ne doit pas se soucier de faire augmenter ou non sa vélocité

Et si nous n’estimions plus ?

#NoEstimate : ne plus estimer en story point mais en « US done » !

Cette méthode est basée sur le débit du nombre de tâches finies en fin de sprint.

Pourquoi changer ? De nombreux exemples montrent que la marge d’erreur entre la prédiction et le réel est bien plus petite lorsqu’on choisit l’« us done » comme estimation, plutôt que les « story points ».

Qu’est-ce que ça implique ? Les responsabilités s’inversent ! Le #NoEstimate repose sur le Product Owner (et/ou PPO).

Pour utiliser cette méthode, les tâches doivent être découpées et rédigées rigoureusement (respect du modèle INVEST) afin que le nombre de tâches done à chaque sprint soit stable. Le backlog gagne alors en qualité, les tâches sont plus fines et la planification de sprint dure moins longtemps.

On tente ?

Author avatar
Jennifer Muscato
En naviguant sur notre site, vous acceptez les cookies 🍪