La plupart des équipes Scrum suivent leur vélocité sprint après sprint. Cet indicateur, basé sur les story points, donne une tendance utile pour la planification, mais il ne dit rien sur la manière dont le travail progresse à l’intérieur du sprint. Les métriques de flux, formalisées par le Kanban Guide for Scrum Teams, rendent visible ce que la vélocité ne capte pas: les blocages, les files d’attente et les éléments qui stagnent.
Quatre métriques, un système cohérent
Les quatre métriques de flux ne fonctionnent pas isolément. Elles forment un système relié par une relation mathématique connue sous le nom de loi de Little: le temps de cycle moyen d’un élément équivaut au travail en cours divisé par le débit. Modifier l’une de ces variables affecte les autres, ce qui donne à l’équipe un levier concret d’amélioration.
Le travail en cours (WIP)
Le WIP (Work in Progress) correspond au nombre d’éléments commencés mais pas encore terminés. Ce n’est pas la même chose qu’une limite de WIP, qui est une contrainte volontaire que l’équipe s’impose. La mesure du WIP réel sert de diagnostic: si une équipe de cinq personnes a régulièrement douze éléments en cours simultanément, le problème n’est pas la capacité individuelle mais la dispersion collective. Un Cumulative Flow Diagram (CFD), graphique qui empile les éléments par état au fil du temps, permet de visualiser cette réalité d’un coup d’œil.
Le temps de cycle (Cycle Time)
Le cycle time mesure la durée calendaire entre le moment où un élément est “commencé” et celui où il est “terminé”, selon la définition de workflow propre à l’équipe. C’est un indicateur retardé: il ne devient disponible qu’après achèvement. Son utilité réside dans l’analyse des tendances. Un scatterplot qui affiche le temps de cycle de chaque élément livré révèle la distribution réelle bien mieux qu’une simple moyenne. Si 85% des éléments sont livrés en moins de cinq jours mais que 15% dépassent les quinze jours, la moyenne masque un problème structurel que le scatterplot rend évident.
Le débit (Throughput)
Le throughput compte le nombre d’éléments terminés par unité de temps, sans pondération par la taille. Cette distinction avec la vélocité est essentielle: la vélocité agrège des story points dont la calibration varie d’une équipe à l’autre, tandis que le throughput mesure un flux brut. Combiné avec les données historiques de cycle time, le throughput permet des prévisions probabilistes plus fiables que les estimations déterministes classiques. Au lieu de dire “nous livrerons 40 points ce sprint”, l’équipe peut affirmer “nous avons 85% de chances de terminer entre 8 et 12 éléments”.
L’âge des éléments en cours (Work Item Age)
Si le cycle time est un indicateur retardé qui ne concerne que les éléments achevés, le work item age est son complément avancé (leading indicator) pour les éléments encore en cours. Il mesure le temps écoulé depuis le démarrage d’un élément jusqu’à l’instant présent. Combiné avec un seuil d’alerte, le Service Level Expectation (SLE), il permet d’identifier les éléments à risque avant qu’ils ne deviennent des retards. Un élément dont l’âge dépasse le 85e percentile historique du cycle time mérite une attention immédiate en Daily Scrum.
Intégrer ces métriques dans les événements Scrum
L’intérêt de ces quatre métriques ne réside pas dans leur collecte mais dans leur utilisation au bon moment.
En Sprint Planning, le throughput historique remplace ou complète les estimations de capacité. Si l’équipe termine en moyenne 10 éléments par sprint avec une fourchette de 8 à 13, cette donnée empirique est plus fiable qu’une estimation basée sur les story points disponibles. Les éléments reportés du sprint précédent, dont le work item age est déjà élevé, doivent être évalués en priorité: les reprendre n’est pertinent que si le problème qui a causé le blocage est résolu.
Le Daily Scrum devient plus ciblé lorsqu’il s’appuie sur le WIP actuel et le work item age. Plutôt que de faire le tour des membres de l’équipe, la discussion se concentre sur les éléments dont l’âge approche ou dépasse le SLE. Cette approche oriente naturellement la conversation vers les obstacles concrets plutôt que vers le reporting d’activité.
En Sprint Review, les tendances de cycle time et de throughput sur plusieurs sprints donnent aux parties prenantes (stakeholders) une vision factuelle de la capacité de livraison. Ces données alimentent aussi la discussion sur la planification des releases: combien d’éléments du backlog peuvent raisonnablement être livrés dans les trois prochains sprints?
La Sprint Retrospective est le moment d’analyser les quatre métriques ensemble. Une augmentation du cycle time malgré un WIP stable peut signaler un problème de qualité en amont. Une baisse de throughput avec un WIP croissant indique une dispersion excessive. Le CFD révèle si certains états du workflow accumulent les éléments, pointant vers un goulet d’étranglement spécifique.
Commencer simplement
L’adoption de ces métriques ne nécessite pas d’outillage complexe. Pour chaque élément du Product Backlog qui entre dans le sprint, il suffit de noter deux dates: le jour où le travail commence effectivement et le jour où il est terminé selon la Definition of Done de l’équipe. La plupart des outils de gestion de projet (Jira, Azure DevOps, etc.) enregistrent déjà ces transitions. L’équipe doit en revanche se mettre d’accord sur ce que “commencé” et “terminé” signifient concrètement dans son contexte: c’est la définition de workflow, préalable indispensable à toute mesure cohérente. En pratique, un minimum de 30 éléments achevés, soit environ trois à quatre sprints de données, est nécessaire pour dégager des tendances significatives.