Définition de la vélocité
La vélocité est le nombre total de points d’effort respectant le Definition Of Done (DOD) à la fin d’une itération. La notion de DOD d’un item est définie par l’équipe et peut varier selon les équipes. Les items démarrés durant l’itération et qui ne respectent pas le DOD ne seront pas pris en compte dans le calcul de la vélocité : tout simplement car un item non terminé est inutilisable et n’apporte aucune valeur au produit final.
Pourquoi utiliser la vélocité dans une équipe agile ?
Il y a plusieurs utilités à calculer la vélocité d’une équipe agile, voici les 3 principales illustrées par des exemples
La vélocité permet d’estimer le nombre de points d’effort à intégrer lors du Sprint Planning
Prenons l’exemple d’une équipe qui a réalisé 30 points lors de son dernier sprint et dont la moyenne sur les 5 dernières itérations est de 33 points. En fin de sprint planning l’équipe a estimé à 42 points la charge du sprint backlog. Sachant qu’un membre de l’équipe sera en congé pendant une semaine, l’équipe va adapter le contenu du sprint backlog pour ne pas se surcharger en sachant qu’elle ne sera pas en capacité de tout réaliser.
La vélocité permet d’anticiper le futur du projet
Si une équipe venait à estimer l’entièreté de son backlog, elle pourrait prédire combien d’itérations seraient nécessaires pour développer de celui-ci : il suffit de diviser le nombre de points du backlog par la vélocité moyenne de l’équipe (il est nécessaire de laisser passer 6 à 8 itérations pour dégager une moyenne correcte).
Un outil visuel (le burnup chart) est présenté plus bas et permet de prédire à quel moment une équipe sera en rupture de charge, ou même de voir d’un coup d’œil si le projet est agile ou pas.
La vélocité permet d’identifier des problèmes d’organisation
Les problèmes d’organisation peuvent être nombreux : un blocage de l’ensemble US en phase de test, un manque de capacité sur une compétence particulière (exemple une équipe qui n’a qu’un seul développeur iOS et qui est absent)
Reprenons l’exemple d’une équipe, qui, lors du précédent Sprint, aurait réalisé seulement 15% de son Sprint Backlog : en analysant lors de sa rétrospective les résultats de son Sprint l’équipe va pouvoir identifier les irritants, problèmes et/ou blocages et trouver un plan d’actions efficace pour pallier aux différents problèmes rencontrés.
Bien entendu, ces soucis peuvent être anticipés en utilisant quotidiennement l’outil burndown chart.
Limites et utilisations proscrites
Le nombre de points défini par l’équipe n’est pas un engagement sur le temps maximal à passer sur une US. C’est une estimation. Si cette estimation à 5 points prend moins de temps que prévue, l’équipe de développement va enchaîner sur la suite du sprint. Elle ne va pas attendre que le temps passe car il a été trop rapide.
« J’aime bien donner cet exemple : on sait dire s’il fait plus chaud dehors que dans une maison, mais on ne sait pas dire la température exacte dans ces deux contextes. C’est donc une estimation relative, et c’est le même principe qui s’applique pour les estimations agiles. »
Ces estimations s’affineront avec le temps et les itérations.
La vélocité est une mesure pour estimer la capacité de réalisation de l’équipe et non un indicateur de productivité ou de performance.
Voici un exemple (à proscrire bien évidemment…) de dérive de la vélocité :
Dans une équipe mature, la vélocité se stabilisera et bougera peu, même si des choses qui pouvaient paraître très difficiles quelques mois auparavant sont maintenant connues et que les estimations pourraient revues à la baisse.
Les sujets seront maîtrisés car l’équipe se connait, connait son produit, son environnement technique… La productivité de l’équipe augmentera car elle pourra embarquer plus d’items dans ses sprints et donc, plus de travail dans le même laps de temps.
A contrario, sa vélocité peut baisser à cause de plusieurs critères ou d’événements qui se produiraient au sein de l’équipe : une nouvelle personne qui intègre l’équipe, part, tombe malade, est en congé… Tous ces éléments sont à prendre en compte lors de la construction du sprint backlog en sprint planning.
Si une équipe a eu une vélocité de 40 au précédent sprint mais qu’une personne de l’équipe est absente, au lieu de surcharger ce sprint au risque de n’en faire qu’une partie il vaut mieux l’alléger. L’important est le ratio global entre le nombre de points à réaliser et le nombre de points terminés (l’idéal étant d’avoir un ratio > 80%) et non pas le nombre de points réalisés sur le sprint.
Comme précisé plus haut, la vélocité reste un outil de calibration abstrait qui permet de faire du macro-planning, elle n’est pas adaptée à la planification fine en sprint planning. Dans une équipe pluri-disciplinaire, les membres ne sont pas interchangeables : il peut y avoir des développeurs front / back, des testeurs, UX designer… l’équipe de développement n’est pas composée uniquement de développeurs. Le nombre de points attribués à une story est une estimation relative et non pas un engagement sur une durée de réalisation.
Il est donc inutile de comparer les vélocités entre les équipes : cela n’a aucun sens et aucun intérêt.
Outils et moyens visuels
Le burndown chart associé au sprint backlog pour un suivi quotidien
Exemple de burndown chart :
Le burndown chart est un outil de suivi de vélocité du quotidien :
– l’axe vertical indique le nombre total de point d’effort à réaliser durant le sprint
– l’axe horizontal indique chaque jour du sprint
Ce burndown chart est représenté par deux courbes :
– La première est l’indicateur, ou plutôt la ligne à suivre pour réaliser un sprint « parfait ». Elle démarre au maximum du nombre de points à réaliser pour se terminer à 0, sur le dernier jour du sprint.
– La seconde représente les tâches terminées au quotidien. Cette courbe doit être mise à jour chaque matin lors du daily meeting de l’équipe pour suivre l’avancement du sprint.
La deuxième courbe peut être révélatrice de plusieurs points :
Si la courbe ne descend pas :
Il y a potentiellement plusieurs sujets bloqués ou la présence d’autres soucis liés à la vie d’un projet (par exemple des incidents de production).
Si un Sprint démarre « mal » :
L’équipe peut le voir tout de suite et peut ainsi mettre en place les actions nécessaires pour se focaliser sur l’objectif du sprint.
Cette courbe permet d’avoir du recul sur les irritants, elle peut également être utilisée lors de la rétrospective pour comprendre ce qui n’a pas fonctionné cette fois-ci. Dans de très rare cas, un sprint peut être stoppé si l’objectif devient obsolète.
Si la courbe descend trop rapidement
Il y a deux possibilités : soit les estimations n’étaient pas bonnes et qu’il faut les retravailler lors du prochain sprint planning, soit l’équipe a pas pris trop peu d’items dans le sprint backlog. Quel que soit le cas identifié, l’équipe devra se remettre en question pour que cela ne se reproduise pas au sprint suivant.
Le burnup chart
Un burnup chart peut être réalisé pour suivre l’avancement global du projet si l’entièreté de la backlog a été estimée, ce chart peut également avoir pour objectif de suivre le nombre d’items de la backlog. C’est à adapter selon le besoin de votre projet et selon votre équipe.
– l’axe vertical représente le nombre total de points d’effort du projet (ou items)
– l’axe horizontal représente les itérations
A la fin de chaque itération, la vélocité (ou bien le nombre d’item réalisés) est ajoutée et la courbe mise à jour. Au fur et à mesure des sprints, l’équipe pourra alors prédire approximativement dans quelle itération le backlog sera terminé.
La courbe verticale est révélatrice de plusieurs choses :
– L’équipe pourra estimer à partir de quel moment elle n’aura plus de travail à réaliser.
– Si le backlog bouge énormément et que le travail à réaliser est toujours supérieur au travail terminé alors un nettoyage du backlog peut s’avérer nécessaire.
– Si la courbe ne monte jamais, c’est révélateur que notre projet n’est pas agile. En effet, un projet qui se veut agile est en constante évolution. C’est le principe de l’empirisme : c’est en faisant et en expérimentant que l’on apprend, et en apprenant de nouvelles choses, nous serons toujours en constante évolution.
Conclusion
La vélocité agile est un outil de prédictibilité des itérations à venir. Elle est destinée uniquement à l’équipe de développement et est alimentée par cette dernière. Une mauvaise utilisation de la vélocité peut entraîner une pression inutile et amener de la frustration ou de la démotivation dans l’équipe.
Dans un prochain article, nous parlerons des alternatives qui existent et notamment d’une autre manière de penser avec le No Estimate : une méthode qui, si elle est bien utilisée, permet de réaliser vos projets, en se concentrant essentiellement sur la valeur et l’incrément du produit…
