Délai d'exécution et temps de cycle

Ces termes sont souvent confondus. Voici des définitions précises :

Délai d'exécution : Le temps total entre le moment où le travail est demandé et le moment où il est livré.

• Le chronomètre démarre : Quand le client/partie prenante demande le travail
• Le chronomètre s'arrête : Quand le client reçoit la valeur

Temps de cycle : Le temps entre le moment où le travail commence et le moment où il est terminé.

• Le chronomètre démarre : Quand quelqu'un commence à travailler sur l'élément
• Le chronomètre s'arrête : Quand le travail est terminé

La relation :

Délai d'exécution = Temps de cycle + Temps d'attente (attente avant le début du travail)

Le délai d'exécution est ce qui importe aux clients. Le temps de cycle est ce que l'équipe contrôle directement. Les deux comptent.

Le délai d'exécution est l'expérience du client. Il a demandé quelque chose — combien de temps avant de l'obtenir ?

Des délais d'exécution courts signifient :

• Rétroaction plus rapide sur les idées
• Capacité à répondre aux changements du marché
• Satisfaction client plus élevée
• Avantage concurrentiel

Mesurer le délai d'exécution révèle :

• Le coût total des files d'attente (souvent 80 %+ du délai d'exécution est de l'attente)
• Où le système ajoute du délai
• Si les améliorations fonctionnent

La plupart des équipes sous-estiment considérablement leur délai d'exécution parce qu'elles ne voient que le temps de cycle. « La fonctionnalité a pris 3 jours à construire » ignore les 3 semaines où elle est restée dans le backlog et la semaine où elle a attendu le déploiement.

Le temps de cycle est l'efficacité interne de l'équipe. À quelle vitesse pouvons-nous terminer le travail une fois que nous commençons ?

Des temps de cycle courts signifient :

• Moins de travail en cours à la fois
• Boucles de rétroaction plus rapides
• Changement de contexte plus facile
• Livraison plus prévisible

Mesurer le temps de cycle révèle :

• Combien de variation existe (un peu ou beaucoup ?)
• Quels types de travail prennent plus de temps
• Si l'équipe devient plus rapide ou plus lente

La variation compte autant que la moyenne. Une équipe avec une moyenne de 5 jours mais une plage de 2 à 20 jours est moins prévisible qu'une avec une moyenne de 7 jours et une plage de 5 à 10 jours.

Suivi manuel (début simple) :

• Enregistrez la date où le travail entre dans « En cours »
• Enregistrez la date où le travail atteint « Terminé »
• Calculez la différence

Outils numériques : La plupart des outils Kanban suivent cela automatiquement :

• Jira : Rapport Temps dans le statut
• Linear : Analytique du temps de cycle
• Trello : Avec des plugins
• Azure DevOps : Graphiques du temps de cycle

Quoi suivre :

• Temps des éléments individuels (pour les tendances et l'analyse)
• Percentiles (50e, 85e, 95e) plutôt que seulement les moyennes
• Répartition par type de travail (les bogues plus rapides que les fonctionnalités ?)
• Tendance au fil du temps (s'améliore ou se détériore ?)

À éviter :

• Utiliser les moyennes seules (elles cachent la variation)
• Inclure les fins de semaine dans les calculs sans réflexion
• Mélanger différents types de travail dans une seule métrique

Une fois que vous avez des données de temps de cycle, utilisez-les pour :

Prévision : « 85 % des éléments comme celui-ci se terminent en 8 jours. Je suis à l'aise de dire que nous l'aurons d'ici vendredi prochain. »

Identification des problèmes : « Cet élément est en cours depuis 12 jours. Notre 85e percentile est de 8 jours. Quelque chose ne va pas — enquêtons. »

Validation de l'amélioration : « Le trimestre dernier, notre temps de cycle médian était de 5 jours. Ce trimestre, c'est 4 jours. Nos changements de processus fonctionnent. »

Dimensionnement approprié : « Les grandes fonctionnalités ont 3 fois la variance du temps de cycle des petites. Décomposons le travail en morceaux plus petits. »

L'aperçu : Le temps de cycle n'est pas seulement un rapport — c'est un outil pour prendre de meilleures décisions sur le moment.