Suivre les bons indicateurs de performance en sprint ne demande pas de tout mesurer. Trois KPIs bien choisis et rigoureusement suivis valent mieux qu’un tableau de bord de quinze métriques que personne ne regarde. Les indicateurs qui comptent vraiment couvrent trois dimensions : la livraison, la qualité et la valeur perçue par l’utilisateur. Voici lesquels retenir et comment les lire.
📌 Ce qu’il faut retenir
Vélocité et Burndown
Les deux piliers pour piloter la livraison et détecter les dérives dès le sprint en cours.
Qualité et valeur livrée
Taux de défauts, NPS et OKR connectent chaque sprint aux objectifs réels de l’entreprise.
Rôles et fréquence
Chaque indicateur a un responsable désigné et un moment précis dans le cycle Scrum.
Quels KPIs de sprint faut-il vraiment suivre ?
La plupart des équipes Agile démarrent avec trop d’indicateurs, puis abandonnent le suivi faute de temps. Le bon réflexe est l’inverse : commencer par trois métriques structurantes, les suivre sans interruption pendant plusieurs sprints, puis en ajouter une quatrième seulement si un angle reste aveugle. Les trois indicateurs de livraison ci-dessous forment cette base.
La vélocité
La vélocité d’équipe représente la somme des story points complétés sur un sprint donné. Elle sert avant tout à planifier les sprints suivants : si l’équipe livre en moyenne 45 points par sprint, vous savez que 500 points de backlog représentent environ onze sprints de travail.
Ce qui la rend utile, c’est aussi ce qui peut la rendre trompeuse. La vélocité fluctue naturellement selon les absences, les congés ou les changements de priorité. Elle se stabilise en général après cinq à six sprints consécutifs. Retenez une règle absolue : comparer la vélocité de deux équipes différentes n’a aucun sens. Les contextes, les produits et les conventions d’estimation sont toujours incomparables.
Le Burndown Chart
Le burndown chart est le graphique d’avancement du sprint. Sur l’axe horizontal, le temps (en jours). Sur l’axe vertical, la quantité de travail restante (en story points ou en heures). Deux courbes se superposent : la trajectoire idéale, calculée au sprint planning, et la trajectoire réelle, mise à jour chaque jour.
Le Scrum Master consulte ce graphique quotidiennement, pas en fin de sprint. C’est précisément là sa valeur : détecter les dérives tôt, quand il reste encore du temps pour ajuster. Une courbe réelle qui reste plate pendant deux jours consécutifs signale un blocage que le daily stand-up doit adresser.
Le rapport planifié-réalisé
Ce ratio compare la charge de travail planifiée au sprint planning à ce qui a effectivement été livré à la fin du sprint. Un rapport régulièrement inférieur à 80 % indique une tendance au sur-engagement lors du planning. Un rapport proche de 110 % révèle l’inverse : l’équipe sous-estime son propre débit.
Suivi sur plusieurs sprints, cet indicateur améliore directement la précision des estimations futures et réduit les frustrations liées aux objectifs non tenus.
Comment calculer ces indicateurs concrètement ?
Connaître le nom d’un indicateur ne suffit pas. Ce qui compte, c’est de savoir comment le calculer sans ambiguïté et comment interpréter ce qu’on lit. Voici les formules et les repères pratiques pour chacun des trois indicateurs précédents.
Calcul de la vélocité
La formule est simple : additionnez les story points de toutes les user stories marquées comme « done » à la fin du sprint, selon la définition de fini convenue par l’équipe. Aucun point partiel. Une story non terminée à 100 % ne compte pas.
Pour planifier un périmètre de livraison, appliquez ensuite ce calcul :
- Nombre total de story points dans le backlog priorisé : par exemple 480 points
- Vélocité moyenne sur les trois derniers sprints : par exemple 48 points
- Nombre de sprints nécessaires : 480 ÷ 48 = 10 sprints
Recalculez cette moyenne à chaque entrée ou sortie d’un membre dans l’équipe. Une équipe qui change de composition voit sa vélocité fluctuer pendant deux à trois sprints avant de retrouver un rythme stable.
Lecture du Burndown Chart
Au sprint planning, tracez la droite idéale en divisant le total de points engagés par le nombre de jours ouvrés du sprint. Chaque jour, mettez à jour la courbe réelle avec les points effectivement restants.
Trois situations à identifier rapidement :
- La courbe réelle descend plus vite que la cible : l’équipe avance bien, vérifiez que le périmètre n’a pas été réduit en cours de route.
- La courbe réelle reste au-dessus de la cible de façon persistante : un blocage ou un sous-engagement au planning est probable.
- La courbe réelle présente des chutes brutales plutôt qu’une descente progressive : les user stories ne sont pas suffisamment découpées en tâches granulaires.
Anti-patterns à éviter sur le Burndown Chart
Certains comportements faussent la lecture du burndown sans que l’équipe s’en rende compte. Les voici, avec le signal qu’ils envoient réellement :
- Sprint terminé trop tôt (jour 5 sur 10) : engagement insuffisant au sprint planning, l’équipe aurait pu viser plus.
- Sprint non honoré malgré une courbe plate : trop de travail accepté, ou des dépendances externes non anticipées bloquent la livraison.
- Périmètre modifié en cours de sprint par le Product Owner : cela invalide la courbe cible et rend le graphique illisible pour le reste du sprint.
- Courbe qui ne bouge pas pendant le premier tiers du sprint : les tâches sont trop grosses, le découpage doit être revu dès la prochaine rétrospective.
Quels indicateurs mesurent la qualité et la valeur livrée ?
La productivité d’une équipe Agile ne se résume pas à la quantité de fonctionnalités livrées. Un sprint qui produit beaucoup mais génère des bugs en production coûte plus qu’il ne rapporte. Deux métriques permettent d’éviter cet écueil, et une troisième connecte le travail de l’équipe aux objectifs stratégiques de l’entreprise.
Le taux de défauts échappés compare les anomalies identifiées pendant les tests à celles découvertes en production par les utilisateurs. Plus ce ratio est élevé, plus la stratégie de test est insuffisante. Chaque bug qui passe en production consomme du temps sur les sprints suivants en corrections non planifiées, ce qui dégrade mécaniquement la vélocité.
Le Net Promoter Score (NPS) pose une seule question à l’utilisateur : quelle est la probabilité qu’il recommande le produit à un collègue, sur une échelle de 1 à 10 ? C’est un outil rapide à mettre en place et cohérent d’un sprint à l’autre. Il valide que ce que l’équipe livre correspond à ce que l’utilisateur perçoit réellement comme utile.
Enfin, connecter les sprints à des OKR (Objectifs et Résultats Clés) garantit que chaque user story développée contribue à un résultat mesurable pour l’entreprise. Un exemple concret : si l’objectif est d’améliorer un service en ligne, les résultats clés pourraient être d’atteindre 10 000 utilisateurs actifs, de collecter 100 avis vérifiés, et de porter le taux de conversion de 10 % à 25 %. Chaque sprint doit pouvoir répondre à la question : quelle contribution ai-je apportée à ces résultats cette semaine ?
Qui doit suivre quoi dans l’équipe ?
Un indicateur sans responsable désigné finit par ne plus être suivi. La répartition suivante clarifie qui produit la donnée, à quelle fréquence, et à quel moment du cycle Scrum.
| Indicateur | Responsable | Fréquence | Moment Scrum |
|---|---|---|---|
| Burndown Chart | Scrum Master | Quotidienne | Daily stand-up |
| Vélocité | Scrum Master | Fin de sprint | Sprint Review |
| Rapport planifié-réalisé | Scrum Master | Fin de sprint | Rétrospective |
| NPS | Product Owner | Fin de sprint | Sprint Review |
| OKR | PO + Direction | Par sprint | Review et Rétrospective |
| Taux de défauts échappés | Équipe Dev | Fin de sprint | Rétrospective |
Sur le plan des outils, la règle est simple : la régularité du suivi prime sur la sophistication de la solution. Une équipe débutante tire davantage de valeur d’un tableur bien tenu, avec des colonnes claires et des couleurs conditionnelles, que d’un outil complexe sous-utilisé. Les équipes intermédiaires peuvent s’orienter vers Notion ou Metabase. Les équipes plus avancées bénéficient de Jira pour le suivi du cycle de vie des tickets, avec des automatisations via Make ou N8N pour alimenter les tableaux de bord sans ressaisie manuelle.
Quelles erreurs faussent la lecture de vos métriques Agile ?
Même avec les bons indicateurs en place, certaines habitudes dégradent leur fiabilité. Les voici :
- Comparer la vélocité entre deux équipes différentes : les conventions d’estimation, les contextes produit et les compositions d’équipe rendent cette comparaison sans valeur opérationnelle.
- Ne pas recalculer la vélocité après un changement d’équipe : toute arrivée ou départ modifie le rythme de livraison pendant plusieurs sprints.
- Laisser le Product Owner modifier le périmètre en cours de sprint : cela invalide le burndown chart et fausse le rapport planifié-réalisé.
- Utiliser les métriques pour évaluer un développeur individuellement : les indicateurs de sprint mesurent le système de travail collectif, pas la performance d’une personne.
- Déconnecter les KPIs de sprint des objectifs stratégiques : sans lien avec les OKR, l’équipe optimise une productivité qui ne contribue pas forcément aux résultats attendus par l’entreprise.
