Lead Time e Cycle Time

Questi termini vengono spesso confusi. Ecco le definizioni precise:

Lead Time: Il tempo totale da quando il lavoro viene richiesto fino a quando viene consegnato.

• L'orologio parte: Quando il cliente/stakeholder richiede il lavoro
• L'orologio si ferma: Quando il cliente riceve il valore

Cycle Time: Il tempo da quando il lavoro inizia fino a quando viene completato.

• L'orologio parte: Quando qualcuno inizia a lavorare sull'elemento
• L'orologio si ferma: Quando il lavoro è completato

La relazione:

Lead Time = Cycle Time + Queue Time (attesa prima che il lavoro inizi)

Il lead time è ciò che interessa ai clienti. Il cycle time è ciò che il team controlla direttamente. Entrambi sono importanti.

Il lead time è l'esperienza del cliente. Ha chiesto qualcosa—quanto tempo ci vuole per ottenerla?

Lead time brevi significano:

• Feedback più rapido sulle idee
• Capacità di rispondere ai cambiamenti del mercato
• Maggiore soddisfazione del cliente
• Vantaggio competitivo

Misurare il lead time rivela:

• Il costo totale delle code (spesso oltre l'80% del lead time è attesa)
• Dove il sistema aggiunge ritardi
• Se i miglioramenti stanno funzionando

La maggior parte dei team sottostima drasticamente il proprio lead time perché vede solo il cycle time. "La funzionalità ha richiesto 3 giorni per essere sviluppata" ignora le 3 settimane in cui è rimasta nel backlog e la settimana di attesa per il deployment.

Il cycle time è l'efficienza interna del team. Quanto velocemente possiamo completare il lavoro una volta iniziato?

Cycle time brevi significano:

• Meno lavoro in corso contemporaneamente
• Cicli di feedback più rapidi
• Cambio di contesto più facile
• Consegna più prevedibile

Misurare il cycle time rivela:

• Quanta variazione esiste (poca o molta?)
• Quali tipi di lavoro richiedono più tempo
• Se il team sta diventando più veloce o più lento

La variazione conta quanto la media. Un team con una media di 5 giorni ma un intervallo di 2-20 giorni è meno prevedibile di uno con una media di 7 giorni e un intervallo di 5-10 giorni.

Tracciamento manuale (inizio semplice):

• Registra la data in cui il lavoro entra in "In Corso"
• Registra la data in cui il lavoro raggiunge "Completato"
• Calcola la differenza

Strumenti digitali: La maggior parte degli strumenti Kanban traccia questo automaticamente:

• Jira: Report Time in Status
• Linear: Analytics del cycle time
• Trello: Con plugin
• Azure DevOps: Grafici del cycle time

Cosa tracciare:

• Tempi dei singoli elementi (per tendenze e analisi)
• Percentili (50°, 85°, 95°) piuttosto che solo medie
• Suddivisione per tipo di lavoro (i bug sono più veloci delle funzionalità?)
• Tendenza nel tempo (sta migliorando o peggiorando?)

Evita:

• Usare solo le medie (nascondono la variazione)
• Includere i weekend nei calcoli senza rifletterci
• Mescolare diversi tipi di lavoro in un'unica metrica

Una volta che hai i dati del cycle time, usali per:

Previsioni: "L'85% degli elementi come questo si completa entro 8 giorni. Mi sento sicuro di dire che lo avremo entro venerdì prossimo."

Identificare problemi: "Questo elemento è in corso da 12 giorni. Il nostro 85° percentile è 8 giorni. C'è qualcosa che non va—indaghiamo."

Validazione dei miglioramenti: "Lo scorso trimestre il nostro cycle time mediano era 5 giorni. Questo trimestre è 4 giorni. Le nostre modifiche al processo stanno funzionando."

Dimensionamento corretto: "Le funzionalità grandi hanno una varianza del cycle time 3 volte superiore a quelle piccole. Suddividiamo il lavoro in pezzi più piccoli."

L'intuizione: Il cycle time non è solo un report—è uno strumento per prendere decisioni migliori nel momento.