Une équipe agile peut multiplier les cérémonies, coller des post-it partout et livrer des versions toutes les deux semaines… sans vraiment savoir si elle progresse. Ce qui fait la différence, ce n’est pas seulement le rythme des sprints, mais la capacité à mesurer ce qui compte vraiment : la qualité de la livraison, la fiabilité des engagements, la fluidité du flux, la santé du produit.
Les KPI agiles (indicateurs clés de performance) ont précisément ce rôle : offrir un tableau de bord simple, visualisable par tous, qui permet de piloter l’équipe dans la durée.
Liste des KPI agiles — visuels, classés, prêts à piloter
Indicateurs Scrum & Kanban pour mesurer l’avancement, la prédictibilité, la qualité et le flow — avec un rendu clair et agréable à lire.
Sprint Scrum
Vélocité : points livrés par sprint (tendance + stabilité).
1. Pourquoi suivre des KPI en agile (sans tuer l’agilité) ?
L’agilité se méfie des usines à gaz : des tableaux de bord surdimensionnés, des reportings hebdomadaires pour faire plaisir au management, des colonnes de chiffres que plus personne ne lit. Pourtant, ne rien mesurer revient à piloter l’équipe à l’intuition, avec tous les biais que cela comporte.
Quelques bénéfices concrets d’un suivi de KPI agile bien pensé :
Objectiver la capacité réelle de l’équipe : savoir combien de story points sont livrés en moyenne par sprint, et non ce que l’on “ressent”.
Rendre visibles les tendances : progression de la velocity, variation du taux de complétion des User Stories, évolution de la densité de bugs.
Outiller les arbitrages : faut-il réduire le périmètre du sprint ? Renforcer les tests ? Revoir les estimations ?
Parler un langage commun entre Product Owner, Scrum Master, développeurs, QA, management.
Le but n’est pas de juger les individus, mais de donner à l’équipe un miroir fiable de son fonctionnement. Un fichier Excel devient alors un instrument de travail collectif, pas un simple reporting imposé.
2. Les principes d’un bon KPI agile
Avant d’entrer dans les détails des formules, quelques principes simples guident la sélection des KPI :
Mesurer peu, mais bien Mieux vaut suivre 6 ou 7 indicateurs qui font vraiment sens pour l’équipe que 25 chiffres que personne ne regarde.
Rester proche du concret Les KPI doivent être directement liés à ce que vit l’équipe : nombre d’User Stories terminées, bugs détectés, capacité réellement délivrée, temps de traversée d’une demande.
Faciliter la comparaison dans le temps Un bon KPI se lit sprint après sprint : il doit permettre d’identifier des tendances, pas seulement une photo isolée.
Être calculable simplement Si le KPI nécessite une extraction complexe ou des manipulations manuelles interminables, il finira par être abandonné. D’où l’intérêt d’un modèle Excel où tout est préparé : colonnes de données, formules automatiques, feuille de synthèse.
3. Les KPI agiles essentiels et leurs formules
Voici une base cohérente de KPI agiles, que l’on peut suivre à l’échelle d’une équipe Scrum. Le modèle Excel que tu as sous la main les intègre déjà dans la feuille Donnees_Sprint.
3.1. Velocity : la capacité de livraison de l’équipe
Définition : nombre de story points terminés par sprint.
Utilité : donne une vision simple de la capacité réelle de l’équipe à livrer du travail “Done”.
Dans la feuille Donnees_Sprint, la velocity d’un sprint est tout simplement la valeur saisie en “Story points terminés” (colonne G). On la recopie en colonne O – Velocity (SP terminés) avec, par exemple à la ligne 2 :
=IF(G2<>"",G2,"")
Sur plusieurs sprints, la velocity moyenne se calcule dans la feuille Synthese :
Cette moyenne ne doit pas devenir une contrainte rigide (“il FAUT livrer 40 SP à chaque sprint”), mais un repère pour calibrer les engagements.
3.2. Fiabilité de l’engagement : tenir ce qui a été promis
Définition : rapport entre les story points terminés et les story points engagés en début de sprint.
Formule conceptuelle :
Fiabilité de l’engagement = SP terminés / SP engagés
Formule Excel (colonne P) :
=IF(F2>0,G2/F2,"")
Un ratio proche de 100 % signifie que l’équipe tient régulièrement ses engagements. Un ratio très variable ou souvent inférieur à 60–70 % signale des engagements trop optimistes, un périmètre instable ou des dépendances mal gérées.
3.3. Focus factor : utiliser la capacité au bon endroit
Définition : part des story points terminés par rapport à la capacité prévue (en story points).
Formule conceptuelle :
Focus factor = SP terminés / capacité prévue
Formule Excel (colonne Q) :
=IF(J2>0,G2/J2,"")
La colonne J – Capacité prévue (story points) permet de prendre en compte les congés, formations, temps partiels… Un focus factor cohérent montre que l’équipe utilise sa capacité pour livrer du “Done”, plutôt que de s’éparpiller entre tâches parasites, interruptions ou multitâche permanent.
3.4. Taux de complétion des User Stories
Définition : proportion d’User Stories terminées par rapport aux User Stories engagées dans le sprint.
Formule conceptuelle :
Taux de complétion US = Nb US terminées / Nb US engagées
Formule Excel (colonne R) :
=IF(H2>0,I2/H2,"")
Ce KPI complète la velocity. Une velocity élevée avec un faible taux de complétion peut révéler que l’équipe entame beaucoup de choses sans les finir, ce qui nuit à la lisibilité pour le Product Owner et les parties prenantes.
3.5. Densité de bugs : qualité du produit livré
Définition : nombre de bugs détectés rapporté au volume de story points terminés, ramené à une base de 100 SP.
Ce KPI ne sert pas à culpabiliser mais à surveiller la tendance : si la densité de bugs explose à chaque sprint, c’est un signal fort pour renforcer les tests, revoir les pratiques de développement ou travailler sur la dette technique.
3.6. Qualité de correction des bugs
Définition : part des bugs corrigés sur l’ensemble des bugs détectés pendant le sprint.
Formule conceptuelle :
Qualité de correction = bugs corrigés / bugs détectés
Formule Excel (colonne T) :
=IF(K2>0,L2/K2,"")
Un ratio proche de 100 % montre que l’équipe ne laisse pas les défauts s’accumuler. À l’inverse, un backlog de bugs non résolus est le signe d’un risque de dégradation de la qualité perçue par les utilisateurs.
3.7. Durée de sprint, lead time et cycle time
Enfin, la feuille de données permet de suivre quelques indicateurs temporels :
Durée de sprint (colonne D) :
=IF(AND(B2<>"",C2<>""),C2-B2+1,"")
Lead time moyen (jours) : temps entre l’expression du besoin et son passage en “Done” (colonne M, saisie ou calculée depuis un autre tableau).
Cycle time moyen (jours) : temps entre le début effectif du travail et le “Done” (colonne N).
Ces données, combinées à la velocity, donnent une image très concrète : Combien de temps faut-il à l’équipe pour transformer une demande en valeur livrée ?
4. Structurer son fichier Excel pour suivre les KPI agiles
Le modèle se structure en trois feuilles complémentaires.
4.1. Donnees_Sprint : le journal de bord
Chaque ligne représente un sprint. L’équipe y saisit :
les dates (début, fin),
sa capacité,
ce qui a été engagé et terminé (story points, User Stories),
les bugs détectés et corrigés,
les lead times / cycle times moyens.
Les formules pré-remplies calculent automatiquement :
la durée de sprint,
la velocity,
la fiabilité de l’engagement,
le focus factor,
le taux de complétion des US,
la densité de bugs,
la qualité de correction.
En pratique, il suffit d’ajouter une ligne par sprint et de laisser Excel faire le reste.
4.2. Catalogue_KPI : la fiche mémo intégrée
Pour chaque indicateur, la feuille Catalogue_KPI rappelle :
le nom,
la catégorie (Flux / Engagement / Qualité / Temps),
la description métier,
la formule conceptuelle,
un exemple de formule Excel.
C’est une manière élégante de documenter le modèle : un nouveau Scrum Master ou un Product Owner peut prendre le fichier et comprendre très vite ce que signifie chaque KPI.
4.3. Synthese : la vue management
La feuille Synthese agrège les informations clés :
nombre de sprints saisis,
velocity moyenne,
fiabilité moyenne des engagements,
focus factor moyen,
taux moyen de complétion des US,
densité moyenne de bugs.
Cette vue est particulièrement utile pour :
les rétrospectives de fin de trimestre,
les échanges avec le management,
la préparation d’un bilan agile ou d’un ajustement de capacité.
5. Bonnes pratiques pour utiliser les KPI agiles sans les subir
Quelques repères pour exploiter ton modèle Excel au mieux :
Co-construire les KPI avec l’équipe : expliquer ce que l’on mesure, pourquoi, comment les chiffres seront utilisés. Un indicateur compris est beaucoup mieux accepté.
Parler logique de tendance, pas de sanction : l’intérêt est d’observer une trajectoire, pas de juger un sprint isolé.
Mettre les KPI au service des rétrospectives : montrer les courbes de velocity, de fiabilité, de bugs ; demander à l’équipe ce qu’elle en retient, quelles actions elle propose.
Rester prêt à ajuster la batterie de KPI : certains indicateurs peuvent être mis en pause, d’autres ajoutés, en fonction de la maturité de l’équipe et des enjeux du moment.
Éviter de transformer le modèle en outil de contrôle purement hiérarchique : dès que les KPI deviennent des armes de pression, l’équipe apprend à “jouer avec les chiffres” et la valeur de la mesure s’effondre.
Un fichier Excel de suivi des KPI agiles constitue un moyen simple et concret de rendre la performance de l’équipe visible, partageable et discutable, quelle que soit la taille de l’organisation. La combinaison d’une feuille de données par sprint, d’un catalogue de KPI documenté et d’une synthèse lisible offre à ton équipe un tableau de bord vivant où les échanges s’appuient sur des faits : capacité de livraison, fiabilité, qualité, temps de traversée. L’agilité repose sur les humains, la collaboration et l’apprentissage, et des KPI bien utilisés soutiennent cette dynamique en fournissant un socle solide pour progresser, sprint après sprint.