Calculateur de Vitesse de Sprint Gratuit

Analysez les tendances de vitesse, détectez les anomalies et prévoyez l'achèvement du backlog avec l'IA

Analyser la Vitesse

Entrez le nom et les points d'histoire complétés pour chaque sprint.

Ajoutez la taille de votre backlog restant en points d'histoire pour obtenir une prévision d'achèvement.

Ajoutez des informations sur votre équipe, la durée des sprints ou les changements récents pour une analyse plus précise.

Sprint Velocity Calculator

Prêt à Analyser Votre Vitesse ?

Entrez vos données de sprint et notre IA calculera les moyennes, détectera les tendances, signalera les anomalies et prévoira l'achèvement du backlog.

Explorer tous les outils gratuits

Découvrez plus d'outils alimentés par l'IA pour aider votre équipe agile à travailler plus intelligemment.

Suivez et analysez la vélocité de votre équipe

La vélocité des sprints est le nombre moyen de points d'histoire qu'une équipe complète par sprint. La plupart des équipes jettent un coup d'œil à la moyenne, la mettent sur une diapositive et passent à autre chose. Mais la moyenne seule cache les éléments intéressants : l'équipe s'accélère-t-elle ? Ralentit-elle ? Est-elle extrêmement incohérente d'un sprint à l'autre ?

Cet outil examine vos données de sprint et extrait ce qu'une feuille de calcul vous prendrait une heure à trouver. Il calcule les tendances, signale les sprints qui semblent inhabituels, mesure la prévisibilité de votre production et estime combien de temps prendra le backlog restant. Collez vos chiffres et obtenez l'image complète.

Ce que vous obtenez en analysant la vélocité de cette manière

Détecter les baisses lentes tôt

Une baisse de 10 % de la vélocité par sprint est invisible lorsque vous regardez un seul sprint à la fois. Sur cinq sprints, cela représente une baisse de 40 % que personne n'a remarquée. Regarder l'ensemble des données rend ces changements graduels évidents, que la cause soit l'accumulation de dettes techniques, l'élargissement du périmètre ou le départ de personnes.

Comprendre pourquoi la vélocité a baissé, pas seulement qu'elle a baissé

Voir que le Sprint 8 était 40 % en dessous de la moyenne ne vous dit rien d'utile en soi. Le croisement avec le contexte de votre équipe pointe souvent vers une raison : peut-être que deux personnes étaient en vacances, ou que l'équipe a commencé une migration que personne n'a bien évaluée.

Répondre à « quand le backlog sera-t-il terminé ? »

La direction va demander. Si vous répondez avec un pressentiment, vous assumez la date que vous choisissez. Si vous répondez avec une prévision basée sur la vélocité et une plage de confiance, vous avez quelque chose de fondé sur des données réelles. Ce ne sera pas parfait, mais c'est mieux que de deviner.

Voir si les changements de processus ont réellement aidé

Vous êtes passé à la programmation en groupe le mois dernier. Cela a-t-il aidé ? Les tendances de vélocité au cours des sprints suivants vous en diront plus qu'une enquête rétro. Il en va de même pour le changement de la durée des sprints, l'ajout d'étapes de révision de code ou l'intégration de nouveaux membres d'équipe.

Tirer le meilleur parti du suivi de la vélocité

La vélocité est un outil de planification, pas une métrique de performance. Gardez cette distinction claire :

1. Utilisez au moins 5-6 sprints de données

Trois sprints de données ne constituent guère un modèle. La vélocité varie naturellement, et vous avez besoin de suffisamment de sprints pour séparer le signal du bruit. Cinq ou six sprints vous donnent une base de référence à laquelle vous pouvez réellement faire confiance pour la planification.

2. Ne comparez pas la vélocité entre les équipes

Les points d'histoire sont relatifs à l'équipe qui les a estimés. Une équipe ayant une moyenne de 30 points n'est pas plus rapide qu'une équipe ayant une moyenne de 20. Les chiffres n'ont de sens que dans le contexte d'une seule équipe au fil du temps.

3. Enquêtez sur les anomalies, ne les punissez pas

Un sprint à faible vélocité pourrait signifier que l'équipe a passé la semaine à réduire la dette technique ou à gérer des urgences de production. Punir les faibles chiffres apprend aux gens à les manipuler. La meilleure réponse est de demander ce qui s'est passé et si l'équipe a besoin de quelque chose.