Auto-évaluation des métriques de flux pour les équipes

Évaluez la façon dont le travail circule dans votre équipe, puis comparez avec les données de flux de votre outil.

Essayez ce bilan de santé en direct

Qu'est-ce qu'une auto-évaluation des métriques de flux ?

Le flux, c'est la manière dont le travail circule dans une équipe, de son démarrage jusqu'à sa fin. Le Guide Kanban définit quatre métriques de flux que toute équipe Kanban doit suivre : le travail en cours, le débit, l'âge des éléments de travail et le temps de cycle. La plupart des équipes peuvent déjà obtenir ces chiffres dans des outils comme Jira, Azure DevOps, Linear ou GitLab. Ce bilan porte sur la façon dont l'équipe vit le flux, pas sur les chiffres eux-mêmes. Chaque personne évalue 10 affirmations de manière confidentielle, sur les définitions partagées, la visibilité du travail, la limitation du travail en cours, le travail bloqué et la prévisibilité. Pendant la discussion, placez les graphiques de flux de votre outil à côté des résultats, puis transformez les scores les plus bas en actions lors d'une rétrospective.

Dimensions

Définitions et visibilité

L'équipe s'accorde-t-elle sur ce qu'est son travail et peut-elle le voir dans son intégralité ?

  • Démarré et terminé

    Nous sommes tous d'accord sur le moment où un travail est considéré comme démarré et sur celui où il est considéré comme terminé.

  • Travail visible

    Tout notre travail, y compris les demandes imprévues, est visible au même endroit.

Limiter le travail en cours

L'équipe maintient-elle le travail inachevé à un niveau assez bas pour que les éléments continuent d'avancer ?

  • Finir avant de commencer

    Nous terminons le travail déjà en cours avant de commencer quelque chose de nouveau.

  • Limites de travail en cours

    Nous maintenons la quantité de travail en cours suffisamment basse pour que les éléments continuent d'avancer.

Travail bloqué

Le travail qui vieillit ou qui est bloqué est-il repéré et traité ?

  • Les plus anciens d'abord

    Nous examinons régulièrement nos éléments inachevés les plus anciens et agissons en conséquence.

  • Blocages levés

    Les blocages sont signalés dès qu'ils apparaissent et levés rapidement.

  • En traitement, pas en attente

    Nos éléments de travail passent plus de temps à être traités qu'à attendre.

Prévisibilité

L'équipe sait-elle combien de temps prend habituellement le travail et le termine-t-elle à un rythme régulier ?

  • Délais connus

    Nous savons combien de temps prend habituellement un travail similaire et planifions en conséquence.

  • Rythme d'achèvement régulier

    Nous terminons les éléments à un rythme régulier plutôt que par grandes vagues.

Apprendre du flux

L'équipe utilise-t-elle ses données de flux pour améliorer sa façon de travailler ?

  • Données de flux en rétro

    Nous examinons nos données de flux en rétrospective et changeons notre façon de travailler en conséquence.

Quand utiliser ce bilan de santé

  • Quand le tableau semble chargé mais que peu de choses semblent se terminer.
  • Quand les graphiques de votre outil révèlent un problème, comme des éléments qui vieillissent ou du travail qui s'accumule, et que l'équipe doit en comprendre les causes.
  • Quand une équipe adopte Kanban ou modifie son flux de travail, pour vérifier que les bases sont en place.

Conseils et astuces

  • Apportez les chiffres. La plupart des outils de suivi savent les représenter : le graphique de contrôle et le diagramme de flux cumulé dans Jira, les widgets de délai et de temps de cycle dans Azure DevOps, Linear Insights ou GitLab Value Stream Analytics.
  • Lorsque les évaluations de l'équipe et les graphiques ne concordent pas, cherchez à comprendre pourquoi. Cet écart est souvent la partie la plus utile de la discussion.
  • Commencez par vos éléments inachevés les plus anciens. Se demander pourquoi chacun est bloqué mène généralement tout droit au blocage ou à la règle qu'il faut changer.
  • Mettez-vous d'accord sur ce que signifient « démarré » et « terminé » avant de comparer les données dans le temps, sinon les chiffres ne voudront pas dire la même chose d'un mois à l'autre.
  • Transformez un ou deux des scores les plus bas en actions lors de votre prochaine rétrospective, puis refaites le bilan quelques semaines plus tard pour voir ce qui a changé.

Foire aux questions

Quelles sont les quatre métriques de flux ?
Le Guide Kanban en définit quatre. Le travail en cours (WIP) correspond au nombre d'éléments démarrés mais pas encore terminés. Le débit est le nombre d'éléments terminés sur une période donnée, par exemple une semaine. L'âge d'un élément de travail indique depuis combien de temps un élément inachevé est en cours, et le temps de cycle mesure la durée qu'un élément terminé a mise entre son démarrage et sa fin.
Qu'est-ce que l'âge d'un élément de travail ?
C'est le temps écoulé depuis le démarrage d'un élément qui n'est pas encore terminé. Contrairement au temps de cycle, on peut le voir pendant que le travail est encore en cours, ce qui permet de repérer tôt ce qui est bloqué. Le Guide Kanban demande aux équipes de veiller à ce que les éléments ne vieillissent pas inutilement, en prenant comme repère le délai d'achèvement attendu.
Quel est le lien entre les métriques de flux et DORA ?
Le délai de mise en œuvre des changements de DORA, c'est-à-dire le temps entre un commit de code et sa mise en production, est une mesure de flux portant sur une partie du processus. Les métriques de flux couvrent tout le parcours, du démarrage à la fin, y compris le travail réalisé avant l'écriture du moindre code. Utilisez l'auto-évaluation des métriques DORA pour la livraison et ce bilan pour la façon dont le travail circule dans l'équipe.
Faut-il un outil pour utiliser ce bilan ?
Non. Les affirmations portent sur la façon dont l'équipe vit le flux, chacun peut donc les évaluer sans données. La discussion est toutefois plus riche avec des chiffres : si votre outil de suivi affiche le temps de cycle, le travail en cours ou les éléments qui vieillissent, apportez ces graphiques.
Comment utiliser les données de flux en rétrospective ?
Examinez les affirmations les moins bien notées à côté du graphique correspondant, par exemple les éléments qui vieillissent ou l'évolution du travail en cours. Cherchez ce qui explique la tendance et mettez-vous d'accord sur un changement à essayer, comme une limite de travail en cours plus basse. Consultez le même graphique lors de la rétrospective suivante pour voir si cela a aidé.
Qui a créé le Guide Kanban ?
John Coleman et Daniel Vacanti. La version actuelle a été publiée en mai 2025 sur kanbanguides.org sous licence Creative Commons. Les affirmations de ce bilan ont été rédigées par TeamRetro. TeamRetro n'est affilié ni aux auteurs ni à Kanban Guides.

Based on the flow metrics in The Kanban Guide (May 2025) by John Coleman and Daniel Vacanti.

Examens médicaux associés