Souvent associée à la méthodologie Scrum, la vélocité agile peut être un outil précieux lorsqu’il s’agit de suivre le travail réalisé par une équipe de développement lors d’un sprint et d’aider à la prédictibilité du suivant. En revanche, mal utilisée, comme un indicateur de performances pour le management par exemple, elle peut s’avérer totalement contre-productive.
Nous allons vous éclairer sur ce qu’est exactement la vélocité agile, sur ce qu’elle peut apporter à vos équipes de développement, et sur ce qu’il ne faut surtout pas en faire.
Qu’est-ce que la vélocité agile ?
La vélocité est un indicateur utilisé sur des projets gérés à l’aide d’une méthode agile, comme Scrum par exemple. La vélocité agile permet de déterminer l’effort qu’est capable de fournir une équipe de développement pour la réalisation des tâches programmées dans un sprint. Elle est exprimée en nombre de points.
Le product owner place dans le product backlog un certain nombre de fonctionnalités à réaliser, ou items généralement formalisées sous la forme de user stories. L’équipe de développement attribue à chaque product backlog item (ou PBI) un certain nombre de points. Ces points représentent à la fois la complexité et la durée de la réalisation du PBI, estimées de façon empirique. Il ne s’agit pas d’une échelle linéaire. La suite de Fibonacci est souvent utilisée.
Aussi, les valeurs pouvant être attribuées sont:
- 1 pour une tâche extrêmement simple, comme la correction d’un libellé par exemple,
- 2, 3, 5 pour une tâche légèrement plus complexe, comme la création d’un formulaire de saisie simple,
- 8, 13, 21, 34, 55, 89, 144 si l’on ne dispose pas de suffisamment d’informations pour estimer correctement cette tâche.
Il existe plusieurs méthodes d’estimation comme le t-shirt sizing par exemple où l’on utilise artificiellement des tailles de t-shirt, ou la plus connue, le poker planning.
La vélocité agile de l’équipe de développement est calculée à l’issue d’un sprint. Il suffit d’additionner les valeurs de tous les PBI entièrement réalisés et livrés durant le sprint. Par exemple, si au terme du sprint, l’équipe a réalisé un PBI avec 5 points, trois PBI avec 3 points, deux PBI avec 1 point, et qu’il reste un PBI avec 3 points en cours de réalisation – non terminé donc, la vélocité agile sera de 16 (le dernier PBI à 3 points n’est pas pris en compte puisqu’il n’est pas terminé).
Mais si la vélocité agile n’est calculée qu’à la fin du sprint, en quoi est-elle un outil de prédictibilité ?
En fait, il va falloir entre trois et cinq sprints pour que la vélocité de l’équipe de développement se stabilise. Le sprint 0 est généralement complexe. Il s’agit de la mise en route de l’équipe dont les membres ne se connaissent pas nécessairement et des processus. La vélocité est rarement très élevée. Elle va augmenter progressivement durant les trois ou quatre premiers sprints, jusqu’à ce qu’elle se stabilise. La vélocité agile est alors optimale et est relativement représentative, même si elle reste une estimation, de l’effort qu’est capable de produire l’équipe durant un sprint.
Comment utiliser la vélocité agile ?
Une fois la vélocité agile stabilisée, il est donc possible 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 PBI à réaliser durant le prochain sprint.
La mise en place d’un burndown chart va permettre de mettre en valeur la vélocité cumulée au cours des différents sprints ainsi que le nombre de points restant dans le product backlog. Grâce à cet outil, il sera possible de manière graphique de suivre la progression des développements et de prévoir le déroulement des prochains sprints en se basant sur la vélocité moyenne de l’équipe de développement.
Il peut être intéressant également de conserver une réserve de points qui ne soit pas directement affectée à la réalisation d’une tâche précise lors d’un sprint. En effet, le principe d’une méthode agile est de pouvoir s’adapter au changement, et il est courant qu’une tâche à réaliser ne soit identifiée qu’en cours de sprint, ou qu’un changement de priorité ou un problème technique entraîne des complications. Cette réserve de points permettra de prendre en compte ces différentes tâches venant s’ajouter aux autres sans pour autant mettre en péril la livraison prévue à la fin du sprint.
Une fois la vélocité agile stabilisée, il est donc possible de choisir les différents PBI qui pourront être embarqués dans le prochain sprint en fonction des points qui leur ont été attribués auparavant. La vélocité dans les sprints suivants devant être à peu près la même que dans le sprint courant, il va être possible de planifier le contenu de plusieurs livraisons à l’avance tout en conservant une faculté d’adaptation.
Il est très important que la vélocité d’une équipe soit stable, et que l’on ne cherche pas à l’augmenter en permanence. La prédictibilité des sprints n’a effectivement de valeur que si la vélocité ne change pas, ou très peu. L’augmentation à tout prix de la vélocité alors qu’elle est stabilisée ne peut avoir qu’un effet négatif sur la réalisation. Elle se fera généralement au détriment de la qualité des développements et de la satisfaction du client.
Ce qu’il ne faut pas faire avec la vélocité agile !
La vélocité agile est un indicateur destiné uniquement à l’équipe de développement et au product owner. Il s’agit d’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.
La vélocité agile ne doit donc pas être utilisée par le management. Les dérives courantes constatées sont la volonté de l’augmenter à tout prix et la mise en concurrence de plusieurs équipes.
Après quelques sprints, la vélocité sera stabilisée, optimale et donnera un indicateur des possibilités de l’équipe. L’augmenter se fera nécessairement au prix de la qualité des livrables produits. Mieux vaut alors se concentrer sur l’expérience et la satisfaction utilisateur plutôt que sur la quantité de fonctionnalités livrées. Augmenter à tout prix la vélocité agile ne fera que fausser l’indicateur, introduire un rythme de travail de moins en moins soutenable, et finalement, démotiver l’équipe projet. La vélocité agile est d’autant moins un indicateur de performance qu’elle peut varier temporairement ou durablement en fonction de la vie de l’équipe. Des développeurs malades, une formation, un changement de scrum master ou même l’intégration de correctifs mineurs en grand nombre sont autant de facteurs susceptibles de diminuer la vélocité agile de l’équipe durant un sprint. Cette baisse de la vélocité n’indiquera en aucun cas une baisse de la productivité.
La vélocité étant un indicateur propre à une équipe, la comparer à celle d’une autre équipe n’a absolument aucun sens. L’équipe ayant une vélocité inférieure peut avoir l’impression de devoir faire ses preuves, ou vouloir l’augmenter artificiellement en surestimant les demandes initiales par exemple. Il est donc probable que l’on se retrouve avec des vélocités qui augmentent, et une productivité réelle qui décroît.
Pour conclure sur la vélocité agile
Vous l’aurez compris, la vélocité agile est un indicateur alimenté par l’équipe de développement et destiné à elle seule. Bien utilisée, elle peut améliorer la prédictibilité sur les sprints à venir. Mal utilisée, elle peut être à l’origine d’une pression accrue sur l’équipe et sa démotivation.
La solution de gestion de projet en ligne Nutcache propose tous les outils nécessaires au calcul et à la gestion de la vélocité agile d’une équipe de développement. N’hésitez pas à profiter de la période de test gratuite de 14 jours pour évaluer Nutcache.
