Mesurer la vélocité du sprint de votre équipe

Lorsqu'elle est mesurée correctement, la vélocité d'un sprint peut vous aider à estimer avec précision la charge de travail de votre équipe, à simplifier la planification des sprints et à aider les chefs de projet à suivre l'avancement de leurs projets.

Qu’est-ce que la vélocité d’un sprint ?

La vélocité d’un sprint est une mesure de la quantité de travail qu’une équipe Agile peut produire au cours d’un cycle de sprint normal. Vous utiliserez deux variables principales pour calculer la vélocité d’un sprint : la quantité de travail que votre équipe Agile a terminée et le temps qu’il lui a fallu pour terminer ce travail.

Il est important de noter que la vélocité de sprint est une mesure descriptive et ne doit pas être utilisée comme un indicateur de réussite. La vélocité d’un sprint ne doit pas être considérée comme un élément à « améliorer ». Il s’agit d’un indicateur difficile à utiliser pour décrire la quantité de travail que votre équipe peut terminer au cours d’un sprint. Bien que vous deviez mesurer la vélocité de sprint de manière cohérente, elle ne doit pas être considérée comme un indicateur de réussite. Si tel est le cas, votre équipe risque de se retrouver surchargée de travail. L’objectif de la vélocité de sprint est de connaître la capacité de votre équipe, et non de l’augmenter.

Comment calculer la vélocité d’un sprint ?

Vous pouvez calculer la vélocité du sprint à l’aide d’une simple équation mathématique : divisez le nombre d’éléments du backlog (ou de story points, si votre équipe utilise cette méthode) par la durée totale de votre sprint en jours.

Par exemple, si votre équipe a 60 éléments de backlog et que la durée moyenne d’un sprint est de 2 semaines, l’équation serait la suivante :

60 éléments de backlog/10 jours = vélocité de sprint de 6

Déterminer ce que votre équipe peut terminer au cours d’un sprint moyen est relativement simple. Commencez par traiter un backlog contenant beaucoup trop d’éléments et voyez combien d’éléments votre équipe peut traiter dans le temps de sprint souhaité. L’objectif n’est pas de terminer tout le backlog, mais d’évaluer le travail que votre équipe peut terminer.

Une autre option avant votre premier sprint consiste à utiliser des stratégies d’estimation de projet pour prédire ce que votre équipe peut terminer. Si vous recherchez des stratégies à utiliser, essayez l’estimation descendante, l’estimation en trois points ou la méthode d’estimation par analogie.

Pourquoi mesurer la vélocité du sprint ?

La vélocité de sprint ne se mesure pas sans raison. Il existe des raisons pratiques (et bénéfiques) pour lesquelles votre équipe devrait mesurer la vélocité de sprint. En voici quelques-unes :

• Facilite la planification des sprints. Pour les responsables de produit et les Scrum Masters, connaître la vélocité de sprint de leur équipe peut faciliter la planification des sprints. Si vous connaissez la vélocité moyenne des sprints de votre équipe, il est plus facile de choisir les bonnes user stories dans le backlog produit pour passer à cette itération sans surcharger votre équipe de développement.

• Gérer les attentes des parties prenantes. Si vos parties prenantes demandent un calendrier pour une user story spécifique ou si elles essaient d’ajouter quelque chose avant la fin du sprint, vous, en tant que Product Owner, comprenez comment ce changement peut affecter le rendement de votre équipe en fonction de sa vélocité de sprint.

• Signaler les problèmes potentiels. Lorsque vous suivez régulièrement la vélocité d’un sprint, vous êtes en mesure de mesurer la vélocité moyenne de manière plus cohérente. Si vous constatez une baisse soudaine de la vélocité, vous savez qu’il existe un problème potentiel, comme un obstacle tel qu’une dépendance inachevée, qui doit être résolu avant de passer au sprint suivant.

Comment visualiser la vélocité du sprint ?

Pouvoir consulter et mesurer la vélocité d’un sprint en un coup d’œil peut aider les personnes travaillant sur un projet Agile à comprendre rapidement les performances de leur équipe. À tout moment pendant le sprint, ils peuvent jeter un coup d’œil à un graphique et voir la progression actuelle de l’équipe. 

Selon ce que vous souhaitez visualiser pour votre sprint, vous pouvez utiliser différents types de graphiques de vélocité. Voici quelques exemples :

Graphique de vélocité de base

Un graphique de vélocité de base est un graphique à barres qui compare deux facteurs principaux : la quantité de travail prévue que votre équipe de développement peut terminer en un sprint et le travail réel qui est terminé en un sprint. 

L’axe horizontal du graphique présente différents sprints, tandis que l’axe vertical affiche le nombre de story points ou de user stories.

En observant ce graphique, vous pouvez facilement voir en moyenne ce que votre équipe peut terminer dans un sprint donné par rapport à la quantité estimée.

Graphique d’avancement

Le graphique d’avancement estime la quantité de travail que votre équipe doit terminer et la compare au temps restant dans le sprint. Au fur et à mesure que le sprint progresse, l'objectif est que la ligne du graphique se rapproche de zéro. 

Si vous disposez d’une estimation de la vélocité de votre équipe, vous pouvez la reporter sur votre graphique d’avancement et comparer les performances de votre équipe à la ligne de vélocité idéale. Dans l’exemple ci-dessus, vous pouvez voir à quel point l’équipe a pu terminer plus de travail que prévu par rapport à la ligne idéale au début du sprint. L’équipe a ensuite connu un ralentissement, mais a tout de même atteint l’objectif final. 

Graphique de progression

Le burnup chart est l’exact opposé du burn-down chart. Ce graphique comprend généralement deux lignes : le travail réellement terminé et l’objectif idéal que vous souhaitez que votre équipe atteigne. L’objectif idéal est généralement une ligne horizontale à travers le graphique, tandis que le travail réel augmentera continuellement pour atteindre la ligne d’objectif au fil du temps.

Conseils pour réguler la vélocité de sprint de votre équipe

Si vous constatez que la vélocité de sprint de votre équipe est irrégulière, cela peut être un signe que vous devez la réguler. La constance de la vélocité d’un sprint est importante, car elle vous permet de visualiser facilement les performances régulières de votre équipe. Les incohérences apparaissent lorsque quelque chose ne va pas.

Par exemple, quatre de vos sprints les plus récents ont eu des vitesses de sprint de 4,5, 7, 5 et 3. La vélocité moyenne de vos sprints est généralement d’environ 6. L’incohérence de la vélocité peut être le signe d’un problème plus important. Réguler la vélocité de sprint de votre équipe signifie essayer de maintenir une vélocité de sprint cohérente d’un sprint à l’autre.

Voici quelques conseils pour y parvenir.

Clarifier les user stories

Pour stabiliser la vélocité de sprint de votre équipe, assurez-vous que les user stories sont claires et faciles à comprendre avant le début du sprint. Un récit utilisateur, ou « user story » en anglais, est une phrase simple décrivant une fonctionnalité logicielle, rédigée du point de vue de l’utilisateur final. Ces user stories sont souvent liées à des éléments d’un backlog. Les membres de l’équipe Scrum ou de l’équipe projet peuvent ainsi se concentrer sur le travail à accomplir, au lieu de passer du temps à rechercher des parties prenantes pour obtenir des informations plus précises. Cela peut vous aider à augmenter votre vélocité en concentrant le temps de votre équipe sur le travail qui compte le plus.

Assurer la cohérence

Si la vélocité de votre équipe est irrégulière, il se peut que vous modifiiez trop de variables d’un sprint à l’autre. Par exemple, remplacez-vous différents membres de votre équipe de développement ? La composition de l’équipe peut modifier la quantité de travail que votre équipe peut accomplir. 

Voici quelques autres variables qui peuvent affecter la vélocité de votre sprint :

• Durée du sprint

• Augmentation des story points

• Changement de processus

Établir une définition uniforme de « terminé »

Il est important que tous les membres de votre équipe comprennent clairement ce que signifie le fait qu’une user story soit « terminée ». Il s’agit d’un aspect clé du cadre Scrum qui est souvent utilisé dans d’autres méthodologies Agile. 

Lorsque votre équipe a une définition claire de ce que signifie un user story terminé, elle est en mesure d’estimer plus précisément la quantité de travail impliquée dans chacun d’entre eux. Cela conduit à des estimations de projet plus précises et, en fin de compte, à une vélocité de sprint plus précise.

Organiser une rétrospective de sprint

La méthodologie Agile est un processus de développement itératif, ce qui constitue l’un de ses principaux avantages. Cela signifie qu’à la fin de chaque sprint, il est possible de revenir sur le sprint précédent et de voir ce qui s’est bien passé et ce qui n’a pas fonctionné. Une réunion de rétrospective de sprint est destinée à cela : une réunion dédiée à la réflexion sur le sprint précédent et à la façon de s’améliorer pour le suivant.

L’objectif est de s’améliorer continuellement. Au fil des sprints, votre équipe doit appliquer les enseignements tirés des sprints précédents aux sprints suivants. Cela donne à votre équipe la possibilité de modifier les processus pour s’améliorer continuellement.