Flow Time Breakdown
Décomposition du cycle time par étape du workflow
Synthèse
Le cycle time total est de 24,53 jours (somme des moyennes par étape), dont 73,7 % — soit 18,08 jours — se passent dans des étapes d'attente sans valeur ajoutée. La Flow Efficiency est de 26,3 % : pour chaque journée de travail effectif, 2,8 journées sont perdues en attente. Le goulot principal est l'étape DEV DONE à elle seule : 17,76 jours en moyenne (72,4 % du cycle time total) — le code est développé mais stagne en attente de code review. C'est une contrainte systémique directement liée à la capacité limitée du lead dev (5 jours/mois). Les 6 autres étapes représentent collectivement seulement 6,77 jours.
Flow Efficiency
Une Flow Efficiency de 26,3 % signifie que pour chaque journée de développement effectif, l'équipe attend 2,8 jours supplémentaires sans qu'aucune valeur soit ajoutée au ticket. Ce chiffre se situe dans la fourchette typique des flux Kanban non optimisés (15–40 %), mais il est quasi-entièrement expliqué par une seule contrainte : l'étape DEV DONE. Sans ce goulot, la Flow Efficiency monterait à environ 86 % — ce qui indique que le reste du workflow est bien conçu. Le problème est structurel et non distribué.
L'étape DEV DONE représente à elle seule 72,4 % du cycle time total. C'est une étape d'attente pure : le développement est terminé mais le ticket stagne en attente de code review. Cette durée (17,76 j en moyenne, 13,99 j en médiane) est cohérente avec le contexte : le lead dev, qui vraisemblablement effectue les code reviews, n'est disponible que 5 jours par mois. Un ticket qui entre en DEV DONE en début de mois peut attendre jusqu'à 3–4 semaines avant que le lead dev soit disponible pour le reviewer.
L'écart moyenne/P50 (+27 %) indique que certains tickets attendent encore plus longtemps — probablement ceux qui entrent en DEV DONE en fin de cycle de disponibilité du lead dev.
Détail par étape du workflow
| Étape | Moy. | P50 | Écart moy/P50 | Part | Story | Bug | Task |
|---|---|---|---|---|---|---|---|
|
Actif
DEV IN PROGRESS
|
1,32 j | 0,63 j | +110 % |
5,4 %
|
1,43 | 0,06 | 0 |
|
Attente
DEV DONE ⚠
|
17,76 j | 13,99 j | +27 % |
72,4 %
|
19,28 | 0,01 | 0 |
|
Actif
PR WIP
|
3,86 j | 1,51 j | +156 % |
15,7 %
|
4,19 | 0 | 0 |
|
Attente
PULL REQUEST DONE
|
0,29 j | 0,06 j | +383 % |
1,2 %
|
0,31 | 0 | 0 |
|
Attente
READY FOR TEST PO
P50 = 0
|
0,03 j | 0 j | — |
0,1 %
|
0,03 | 0 | 0 |
|
Actif
PO TESTING
P50 = 0
|
0,57 j | 0 j | — |
2,3 %
|
0,62 | 0,04 | 0 |
|
Actif
HAVE TO FIX
P50 = 0
|
0,70 j | 0 j | — |
2,9 %
|
0,76 | 0 | 0 |
| Total | 24,53 j | — | — | 100 % | — | — | — |
⚠ PR WIP — Écart moyenne/P50 de +156 % : la médiane est 1,51 j mais la moyenne monte à 3,86 j. Une minorité de Pull Requests stagnent très longtemps en review (outliers tirant la moyenne), pendant que la majorité se traite en moins de 2 jours.
Risques identifiés
-
DEV DONE : contrainte de capacité du lead dev non résolue
Probabilité élevée — Impact élevé72 % du cycle time est bloqué par une capacité de review de 5 jours/mois. Sans augmenter cette capacité ou redistribuer le processus de review, le cycle time global ne peut structurellement pas descendre sous ~18 jours.
-
PR WIP : outliers non identifiés et non traités
Probabilité élevée — Impact élevéL'écart de +156 % entre moyenne (3,86 j) et P50 (1,51 j) indique des PR qui stagnent anormalement longtemps. Sans suivi actif des PR ouvertes, ces tickets dégradent silencieusement la moyenne et alimentent potentiellement le backlog de DEV DONE.
-
HAVE TO FIX : taux de rejet PO non mesurable
Probabilité moyenne — Impact élevéP50 = 0 indique que la majorité des tickets ne passent pas par HAVE TO FIX — mais la moyenne de 0,70 j révèle qu'une minorité génère des corrections après validation PO. Sans connaître ce taux, l'impact sur la capacité réelle est sous-estimé.
-
Flow Efficiency masquant une amélioration difficile
Probabilité moyenne — Impact moyenLa Flow Efficiency de 26 % est quasi-entièrement déterminée par DEV DONE. Toute amélioration des autres étapes (moins de 6 j au total) aura un impact marginal sans traitement du goulot principal.
Recommandations
-
Priorité haute Capacité équipe ↳ DEV DONE −12 à −15 j potentiels Augmenter la disponibilité de review du lead dev ou redistribuer la responsabilité
DEV DONE absorbe 72 % du cycle time à cause de la contrainte de 5 jours/mois du lead dev. Trois leviers possibles : (1) augmenter sa disponibilité sur ce projet, (2) former le développeur fullstack à effectuer des auto-reviews ou des peer-reviews partielles pour les PR de faible risque, (3) définir un SLA de review interne (ex : toute PR reviewée sous 3 jours ouvrés maximum). Réduire DEV DONE de 17,76 j à 3–5 j réduirait le cycle time total de 50–60 %.
Impact attendu : réduction du cycle time total de ~18 j à ~7–10 j, Flow Efficiency passant de 26 % à 60–70 %.
-
Priorité haute Gestion du WIP ↳ DEV DONE Limiter le WIP en DEV DONE à 2 tickets maximum
Sans limite de WIP à l'étape DEV DONE, des tickets peuvent s'accumuler et attendre plusieurs cycles de disponibilité du lead dev. Une limite à 2 tickets force le développeur fullstack à ne pas commencer de nouveau développement tant que 2 tickets attendent déjà une review — cela crée une pression naturelle pour résoudre le goulot plus rapidement et évite l'accumulation silencieuse.
Impact attendu : réduction du temps d'attente en DEV DONE, visibilité immédiate du goulot en temps réel.
-
Priorité moyenne Processus ↳ PR WIP −1 à −2 j potentiels Identifier et traiter les PR outliers (moyenne 3,86 j vs P50 1,51 j)
L'écart de +156 % entre moyenne et P50 de PR WIP indique une minorité de Pull Requests qui stagnent anormalement. Mettre en place un suivi actif des PR de plus de 3 jours (alerte automatique dans GitHub/GitLab), investiguer si ces PR sont trop larges, trop complexes, ou en attente d'une décision externe.
Impact attendu : réduction de la moyenne PR WIP vers le P50 (1,51 j), soit une économie de ~2,35 j sur le cycle time total.
-
Priorité moyenne Mesure ↳ PO TESTING + HAVE TO FIX Mesurer le taux de tickets passant par PO TESTING et HAVE TO FIX
P50 = 0 pour PO TESTING et HAVE TO FIX signifie que la majorité des tickets ne passent pas par ces étapes, mais les moyennes (0,57 j et 0,70 j) révèlent qu'une minorité y passe du temps. Connaître le pourcentage de tickets concernés permettrait de calculer le taux de rejet PO réel et d'identifier si HAVE TO FIX est un signal de qualité à surveiller.
Impact attendu : meilleure compréhension de la qualité livrée et de la capacité réelle consommée par les corrections post-validation.
Questions pour la rétrospective
- Le lead dev effectue-t-il lui-même les code reviews ? Si oui, existe-t-il un moyen de planifier ces reviews à une fréquence plus élevée dans son agenda des 5 jours/mois ?
- Quelles sont les Pull Requests qui ont dépassé 5 jours en PR WIP ? Avaient-elles des caractéristiques communes (taille, complexité, dépendance) ?
- Quel pourcentage de tickets passe par l'étape HAVE TO FIX ? Ce taux augmente-t-il ou diminue-t-il ?
- Si on réduisait DEV DONE à 3 jours maximum, quel serait l'impact sur le cycle time global et sur la satisfaction des parties prenantes ?