Autovalutazione delle metriche di flusso per i team

Verifica come il lavoro scorre nel tuo team e confrontalo con i dati di flusso del tuo strumento.

Provi questo controllo dello stato di salute in tempo reale

Che cos'è un'autovalutazione delle metriche di flusso?

Il flusso è il modo in cui il lavoro attraversa un team, da quando viene iniziato a quando viene completato. La Guida Kanban indica quattro metriche di flusso che ogni team Kanban deve monitorare: work in progress, throughput, età degli elementi di lavoro e cycle time. La maggior parte dei team può già ricavare questi numeri da strumenti come Jira, Azure DevOps, Linear o GitLab. Questo check non chiede quali siano i numeri, ma come il team vive il flusso. Ogni persona valuta in forma riservata 10 affermazioni su definizioni condivise, visibilità del lavoro, limitazione del work in progress, lavoro bloccato e prevedibilità. Quando discutete i risultati, affiancateli ai grafici di flusso del vostro strumento, poi trasformate i punteggi più bassi in azioni durante una retrospettiva.

Dimensioni

Definizioni e visibilità

Se il team è d'accordo su cosa sia il proprio lavoro e se riesce a vederlo tutto.

  • Iniziato e completato

    Siamo tutti d'accordo su quando un lavoro si considera iniziato e quando si considera completato.

  • Lavoro visibile

    Tutto il nostro lavoro, comprese le richieste non pianificate, è visibile in un unico posto.

Limitare il work in progress

Se il team mantiene il lavoro non completato abbastanza basso da far avanzare gli elementi.

  • Finire prima di iniziare

    Completiamo il lavoro già in corso prima di iniziare qualcosa di nuovo.

  • Limiti al work in progress

    Manteniamo la quantità di lavoro in corso abbastanza bassa da far sì che gli elementi continuino ad avanzare.

Lavoro bloccato

Se il lavoro che invecchia o è bloccato viene notato e gestito.

  • Prima gli elementi più vecchi

    Controlliamo regolarmente i nostri elementi non completati più vecchi e interveniamo.

  • Blocchi rimossi

    I blocchi vengono segnalati non appena compaiono e rimossi rapidamente.

  • In lavorazione, non in attesa

    I nostri elementi di lavoro passano più tempo in lavorazione che fermi in attesa.

Prevedibilità

Se il team sa quanto tempo richiede di solito il lavoro e lo completa a un ritmo costante.

  • Tempi noti

    Sappiamo quanto tempo richiede di solito un lavoro simile e pianifichiamo di conseguenza.

  • Ritmo di completamento costante

    Completiamo gli elementi a un ritmo costante anziché a grandi ondate.

Imparare dal flusso

Se il team usa i propri dati di flusso per migliorare il modo in cui lavora.

  • Dati di flusso nelle retro

    Nelle retrospettive guardiamo i nostri dati di flusso e, in base a questi, cambiamo il nostro modo di lavorare.

Quando utilizzare questo controllo dello stato di salute

  • Quando la board sembra piena ma si completa poco.
  • Quando i grafici del vostro strumento mostrano un problema, come elementi che invecchiano o lavoro che si accumula, e il team deve parlarne per capirne il motivo.
  • Quando un team inizia a usare Kanban o cambia il proprio flusso di lavoro, per verificare che le basi siano solide.

Consigli e suggerimenti

  • Portate i numeri. La maggior parte degli strumenti di tracciamento può rappresentarli in grafico, ad esempio il control chart e il cumulative flow diagram in Jira, i widget di cycle time e lead time in Azure DevOps, Linear Insights o GitLab Value Stream Analytics.
  • Quando le valutazioni del team e i grafici non coincidono, parlate del perché. Spesso quella differenza è la parte più utile della discussione.
  • Partite dagli elementi non completati più vecchi. Chiedersi perché ognuno sia bloccato di solito porta dritti al blocco o alla regola da cambiare.
  • Mettetevi d'accordo su cosa significano "iniziato" e "completato" prima di confrontare i dati nel tempo, altrimenti i numeri non avranno lo stesso significato da un mese all'altro.
  • Trasformate uno o due dei punteggi più bassi in azioni nella prossima retrospettiva e ripetete il check dopo qualche settimana per vedere cosa è cambiato.

Domande frequenti

Quali sono le quattro metriche di flusso?
La Guida Kanban ne elenca quattro. Il work in progress (WIP) è il numero di elementi iniziati ma non ancora completati. Il throughput è il numero di elementi completati in un determinato periodo, ad esempio una settimana. L'età degli elementi di lavoro indica da quanto tempo un elemento non ancora completato è in corso, mentre il cycle time indica quanto tempo ha richiesto un elemento completato dall'inizio alla fine.
Che cos'è l'età degli elementi di lavoro?
È il tempo trascorso dall'inizio di un elemento, per il lavoro non ancora completato. A differenza del cycle time, è visibile mentre il lavoro è ancora in corso, quindi segnala per tempo quando qualcosa si è bloccato. La Guida Kanban chiede ai team di assicurarsi che gli elementi non invecchino inutilmente, usando come riferimento il tempo di completamento previsto.
Che rapporto c'è tra le metriche di flusso e DORA?
Il change lead time di DORA, cioè il tempo che passa dal commit del codice alla sua esecuzione in produzione, è una misura di flusso relativa a una parte del processo. Le metriche di flusso coprono l'intero percorso da iniziato a completato, compreso il lavoro che precede la scrittura del codice. Usate l'Autovalutazione delle metriche DORA per la delivery e questo check per capire come il lavoro scorre nel team.
Serve uno strumento per usare questo check?
No. Le affermazioni chiedono come il team vive il flusso, quindi chiunque può valutarle senza dati. Con i numeri, però, la discussione è più efficace: se il vostro strumento mostra cycle time, work in progress o elementi che invecchiano, portate quei grafici.
Come si usano i dati di flusso in una retrospettiva?
Guardate le affermazioni con le valutazioni più basse accanto al grafico corrispondente, ad esempio gli elementi che invecchiano o il work in progress nel tempo. Chiedetevi cosa causa quell'andamento e concordate un cambiamento da provare, come un limite più basso al work in progress. Alla retro successiva controllate lo stesso grafico per vedere se ha funzionato.
Chi ha creato la Guida Kanban?
John Coleman e Daniel Vacanti. La versione attuale è stata pubblicata a maggio 2025 su kanbanguides.org con licenza Creative Commons. Le affermazioni di questo check sono state scritte da TeamRetro. TeamRetro non è affiliata agli autori né a Kanban Guides.

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

Controlli sanitari correlati