La vélocité est indicateur très utilisé en agilité, en Scrum notamment.
La vélocité d’une équipe sur un sprint se mesure en Points (d’effort relatif) et correspond à la somme des points associés aux STORIES qualifiés de DONE à la fin de ce sprint.
Le pré requis : que les stories et une grosse partie du Backlog aient été estimés en Points au préalable.
Jusque là tout va bien… puisque il ne s’agit que de faire une somme. Et puis l’indicateur est précieux puisqu’il donne de la visibilité notamment sur le chemin à accomplir pour terminer une Release, atteindre un périmètre :
Mon backlog de release fait 100 points, notre vélocité après 4 sprints s’est stabilisée autour de 10 points => nous aurons besoin 10 sprints de 2 semaines pour Terminer…
On ne peut plus simple !
L’alerte ne se situe pas tant là, au niveau de l’Equpe Scrum (les dev ou équipiers + PO + ScrumMaster) mais plutôt à l’extérieur de celle-ci (Management, Programme), dans un contexte de Scrum à l’echelle. En effet, dés lors que plusieurs équipes agiles émergent, la tentation est grande de
- COMPARER… de comparer au final CE QUI N’EST PAS COMPARABLE! Ta vélocité n’est pas vélocité
- SE FOCALISER UNIQUEMENT sur ce seul indicateur pour juger la performance des équipes: 10 de vélocité, 3 coups de bâton; 30 de vélocité, 3 chocolatsJ
Repeat after me…
LA VELOCITE EST PROPRE A UNE EQUPE, FONDEE SUR SES PROPRES ELEMENTS DE REFERNCE, IL EST INUTILE ET STUPIDE DE LES COMPARER.
La valeur apportée par l’indicateur vélocité est souvent discutée. Encore dernièrement, Esther Derby en faisait sa cible avec des arguments sonnant juste pour tous ceux qui ont derrière eux quelques années d’Agilité :
- la vélocité est facilement manipulable (c’est vrai, je l’ai vu, côté management, côté Equipe),
- la vélocité est facilement mal utilisée (c’est le propos de cette alerte)
- la vélocité n’est pas la meilleure métrique dans un contexte de transition agile.
Mon challenge :
- Sensibiliser Directions, Management et Programmes sur la question des indicateurs agiles (notamment la vélocité) et des estimations (agiles)
- Former et accompagner les équipes SCRUM sur la façon de réaliser les estimations (Release planning, Planning poker….) et sur les indicateurs à fournir toujours adaptés au contexte
- Eviter toute dérive de comparaison entre équipes
- Proposer d’autres indicateurs (lead time, qualité initiale, WIP, Items bloqués, satisfaction de l’Equipe, risques, taux d’occupation, obstacles, prédictibilité…)
- Re-instaurer la CONFIANCE, car ces mauvaises usages et interprétations traduisent le plus souvent un déficit de CONFIANCE au sein de l’organisation
Mes autres Alertes:
- Alerte Agile n°8: 1 point=2Jours
- Alerte Agile N°7: Notre Product Owner va craquer
- Alerte Agile N°6 : Le dailyScrum c’est pour qui au juste ?
- Alerte Agile N°5 : où sont les testeurs ?
- Alerte Agile N°4: Mon ScrumMaster en fait trop !
- Alerte Agile N°3 : des priorités… ah bon ?
- Alerte Agile N°2: un backlog… quel backlog ?
- Alerte Agile N°1: votre équipe manque de rythme !
