Come usare le Flow metrics per pianificare in modo più accurato – 2° parte

Come usare le Flow metrics per pianificare in modo più accurato – 2° parte

- di and
Come usare le Flow metrics per pianificare in modo più accurato – 2° parte

Come usare le Flow metrics per pianificare in modo più accurato?

Nella prima parte del post, noi – Giuseppe Romeo, Scrum Master @ Hudl e Andrea Pacchioni, Product Manager of Recruitment @ Wyscout – Hudl, abbiamo condiviso con voi la nostra esperienza con le flow metrics, uno strumento validissimo per team di prodotto per poter pianificare con maggior sicurezza e serenità. 

In questa seconda parte del post ci occuperemo, tra le altre cose, del Forecasting, della scelta dei dati (Big caveat), come si calcolano le Flow metrics, come possono essere proposte.

Cosa vedremo in questo post:

Come usare le Flow metrics per pianificare in modo più accurato – 2° parte

I vantaggi nell’adozione delle flow metrics

Forecasting

Vediamo come fare in concreto a passare ad un approccio probabilistico, in particolare al forecasting, nel product development. Nell’ipotesi di aver stabilizzato il nostro sistema con gli opportuni accorgimenti che avremo ideato nel gruppo di lavoro, le nostre metriche di flusso ci consentono di fare agilmente due tipi di forecast:

  • Per i tempi di completamento del singolo Work Item; 
  • Per i tempi di completamento di un insieme di Work Item o viceversa l’insieme di Work Item completabile in un certo intervallo di tempo

Forecast per singolo Work Item e Service Level Expectation (SLE)

Raccogliendo i Cycle Time storici per un periodo di osservazione, possiamo fare affermazioni come:

  1. Con una probabilità dell’85%, non appena inizieremo a lavorarci, completeremo questo Work Item entro 5 giorni di calendario;
  2. Sono passati 2 giorni, da quando abbiamo iniziato a lavorare questo Work Item, la probabilità di finire entro 6 giorni è scesa al 70%;

Che sono forecast propriamente detti: un range di valori con una probabilità associata.

Gli strumenti di calcolo per ottenere affermazioni del genere sono molto semplici: invece delle medie, si usano i percentili.

Per la prima osservazione, ad esempio, basta calcolare l’85mo percentile.

L’85mo percentile dei nostri Cycle Time è quel valore che maggiore o uguale dell’85% dei Cycle Time raccolti: dà quindi la probabilità di completamento all’85% del nostro dataset.

Concretamente, per il calcolo del percentile si ordinano in modo crescente i nostri Cycle Time e si prende il valore che è maggiore o uguale dell’85% dei Cycle Time, come in figura.

Nell’esempio mostrato, immaginando di aver campionato dei Cycle Time che sono la durata in giorni dei nostri Work Item, possiamo dire che l’85mo percentile è 7: quando iniziamo un Work Item nuovo abbiamo una probabilità dell’85% di finirlo entro 7 giorni.

L’85mo percentile è significativo perché di solito viene scelto dai team come Service Level Expectation, ovvero il forecast di riferimento per il singolo Work Item. Noto il loro SLE, i team possono intervenire attivamente sui loro workflow per migliorarlo o, come minimo, per rispettarlo.

Passiamo alla seconda affermazione. 

I percentili più significativi, oltre all’85mo, sono in genere il 50mo e il 70mo. Se il SLE coincide con l’85mo percentile permette di identificare delle soglie quando l’età di un Work Item raggiunge il percentile “notevole”. Ad esempio:

  • Work Item Age = 0 (appena messo in progress): la probabilità di rispettare il SLE è dell’85%
  • Work Item Age = 50mo percentile: la probabilità di  rispettare il SLE è del 70%
  • Work Item Age = 70mo percentile: la probabilità di rispettare il SLE è del 50%, il lancio di una moneta

Per calcolare questi valori servono un po’ di probabilità condizionate (vi risparmio questo dettaglio), ma il punto è che adesso abbiamo informazioni molto più utili per prendere decisioni di prodotto. E i percentili possono diventare vere e proprie soglie di intervento in cui il team si riunisce e valuta il da farsi.

Insieme di Work Item, simulazioni di Monte Carlo

Quando invece vogliamo prevedere quando completeremo un certo insieme N di Work Item e non uno solo (ad esempio quei 5 Work Item che costituiscono il nostro Minimum Viable Product), ci vengono in aiuto le simulazioni di Monte Carlo.

Le simulazioni di Monte Carlo sono un metodo matematico che viene utilizzato per stimare i risultati possibili di un evento incerto. Il metodo si basa sull’idea di generare un numero elevato di simulazioni dell’evento, ciascuna delle quali ha un risultato diverso. Il risultato finale della simulazione è una distribuzione di probabilità dei possibili risultati.

Qui l’evento incerto che ci interessa è il completamento di 5 Work Item, e un modo per fare simulazioni di questo evento è campionare lo storico un’altra metrica di flusso, il Throughput.

Consideriamo ad esempio il Throughput giornaliero di un periodo di riferimento, ad esempio di 28 giorni (vedi figura).

L’idea è che il nostro team si comporterà più o meno in questo modo anche in futuro (nei forecast usiamo il passato per predire il futuro), e quindi possiamo costruire una simulazione campionando in modo casuale i valori di throughput.

Ad esempio nella prima simulazione il campionamento casuale fa sì che finiamo 5 item in 5 giorni. Facciamo poi una seconda simulazione e finiamo in 3 giorni, e così via.

Quando le simulazioni diventano dell’ordine delle migliaia, e contiamo i risultati, abbiamo una buona approssimazione della distribuzione di probabilità dell’evento “in quanti giorni completeremo 5 Work Item”.

La figura seguente, ottenuta da 3000 simulazioni, si legge così:

  • in 83 simulazioni su 3000 abbiamo completato 5 Work Item in 2 giorni
  • in 148 simulazioni su 3000 abbiamo completato 5 Work Item in 3 giorni
  • in 198 simulazioni su 3000 abbiamo completato 5 Work Item in 4 giorni

E adesso potremo fare affermazioni del tipo: “finiremo 5 Work Item entro 16 giorni con una probabilità dell’85%, entro 12 giorni con una probabilità del 70%, entro 9 con una probabilità del 50%”. Di nuovo, come strumento matematico, basta prendere i corrispondenti percentili degli esiti delle simulazioni (es. nell’85% delle simulazioni il risultato è stato entro i 16 giorni).

Abbiamo finalmente le probabilità della delivery, essenziali per poter prendere impegni, definire giorni di lancio sul mercato e così via.

Le simulazioni di Monte Carlo rispondono altrettanto bene alla domanda: quanti Work Item riusciremo a fare in M giorni (es. in 14 giorni)? E anche qui potremo rispondere: 4 o più con una probabilità dell’85%, 6 o più con il 70%, 8 o più con il 50%.

Anche queste probabilità sono utilissime per quei casi in cui sono fissati i periodi di lavoro (es. un trimestre o due settimane di sprint) e si vuole capire cosa è realistico ottenere in questi intervalli di tempo.

Non entriamo nel merito per brevità, ma le simulazioni sul numero di Work Item entro un intervallo di tempo si costruiscono in modo piuttosto simile a quello visto.

Big caveat: la scelta dei dati

Ricordiamo due grandi presupposti di questo approccio al forecasting:

  • Abbiamo stabilizzato il “sistema team”
  • Ipotizziamo che il futuro somigli all’insieme di dati su cui abbiamo basato i nostri forecast.

Dati questi due presupposti non serve una grande quantità di dati, nella maggior parte dei casi basta una 20na di giorni di campionamento, e di solito i dati migliori sono i più recenti. Considerare periodi più lontani o particolari (per esempio quelli pieni di assenze) sarebbe poco rappresentativo per la previsione che volete fare. 

Continuous forecasting

Ciliegina sulla torta: questo approccio al forecasting è molto meno costoso di approcci molto meno affidabili basati su stime di effort e medie. Non servono grandi sessioni di stima e meeting interminabili, per controllare il flusso di lavoro servono solo buone abitudini. 

I forecast si possono ripetere frequentemente, per esempio incorporando gli ultimi dati del throughput giornaliero del team. 

Non è un vantaggio da poco, quando le deadline di business si avvicinano, capire progressivamente qual è la probabilità di farcela.

Come usare le Flow metrics per pianificare in modo più accurato

Come iniziare?

Immaginiamo che vi siate resi conto della potenza di fuoco di che avete a disposizione quando si presta attenzione al flusso di lavoro e si inizia a misurare quest’ultimo tramite le metriche che vi abbiamo presentato. 

Per iniziare ogni gruppo trova la sua strada, possiamo dirvi quattro aspetti che ci hanno messo in carreggiata nei team con cui abbiamo lavorato.

Visualizzare il workflow

Una kanban board che mostri trasparentemente il lavoro, aggiornata regolarmente è il passo zero. Si possono usare board fisiche o adesso più comunemente virtuali. Praticamente ogni tool di ticketing o di “lavagna” sta introducendo kanban board di più o meno elastiche per rappresentare i workflow.

All you need is… timestamp!

Per calcolare tutte le flow metrics, il passo zero è avere sulla card che rappresenta il Work Item l’istante esatto in cui è passato nella colonna “start”, e infine quello in cui è passato nella colonna “stop”. 

Dall’esempio riportato nella figura seguente si vede che i timestamp (insieme alla data odierna) permettono di calcolare le metriche di flusso principali di cui abbiamo parlato con un po’ di sottrazioni e conteggi.

Ci sono ovviamente molti software che registrano i timestamp e calcolano le flow metrics per noi direttamente, ma è importante saper fare questi calcoli per poter valutare il tool che più fa al caso nostro, nel caso fossimo nella condizione di valutarlo. 

Munirsi quindi dei tool (o dei plugin) giusti, o dell’abitudine di scrivere i timestamp, è essenziale.

Non tutte le dimensioni passano dalla porta (lo start)

Per avere un sistema stabile, che abbia le caratteristiche che abbiamo visto, un primo “trick” è non accettare che Work Item di dimensioni arbitrariamente grandi vengano messi nella colonna start. Devono essere Work Item che conosciamo abbastanza da dire che somigliano a quelli che gestiamo di solito, che avranno un Cycle Time comparabile.

Se il team ha definito il suo SLE, il Cycle Time di riferimento, che abbiamo visto in precedenza, basta chiedersi: ci aspettiamo che questo Work Item abbia un Cycle Time entro il nostro SLE? Se la risposta è no, meglio raccogliere ulteriori dettagli o dividere il lavoro in più Work Item, prima di iniziare.

Controllare attivamente il flusso

Infine, serve un checkpoint frequente (giornaliero ad esempio) per controllare i nostri Work Item, ed in particolare quelli “anomali”, che stanno prendendo più tempo del previsto, i più “anziani”.

E le soglie di intervento basate sulla Work Item Age che abbiamo discusso in precedenza sono il miglior punto di partenza. Individuate le anomalie, dovute a dipendenze, impedimenti, insufficiente chiarezza, incomprensioni tra colleghi e chi più ne ha più ne metta, usiamo l’intelligenza collettiva del team per gestirle, se possibile, e ripristinare una condizione di stabilità.

Prossimamente

Ci rendiamo conto che la panoramica di questo mondo è stata veloce, e probabilmente ha solo stimolato l’appetito (sappiamo che adesso non potrete più ordinare un panino senza pensare alle flow metrics!).

In un prossimo articolo vedremo:

  • Come applicare tutto questo ad uno Scrum Team
  • Un caso studio

Intanto, vi rimandiamo al lavoro di Daniel Vacanti, Klaus Leopold e varie risorse che potrete trovare spulciando ProKanban.org e Scrum.org, che sono stati fondamentali per iniziare questo stesso percorso per noi.

Work Cited
– Vacanti, Daniel S. Actionable Agile Metrics for Predictability: An Introduction

Per non perdere nessuno dei nostri contenuti, iscriviti alla newsletter di Product Heroes!

Andrea Pacchioni

Product Manager of Recruitment @ Wyscout - Hudl. Andrea è Product Manager in Wyscout (Hudl), piattaforma che aiuta i club calcistici nello scouting di talenti emergenti. È stato studente del Master in Product Management in Talent Garden e ha ricoperto lo stesso ruolo a MINT

Giuseppe Romeo

Scrum master e agile coach, sono appassionato di agile e product management dal 2009, quando ho avuto la fortuna di unirmi ad una delle prime realtà italiane che sperimenta l’agile in ambito finanziario. Da lì in poi ho ricoperto i ruoli di team manager, scrum master e agile coach, sempre accompagnando la pratica attiva con studio e certificazioni.

Le slide sono disponibili per studenti ed ex studenti del Master in Product Management

Accedi a "Agile Starter Kit" Gratis

Iscriviti alla newsletter e accedi ad Agile Starter Kit: la cartella che contiene oltre 70 pagine su Agile, Scrum / Kanban, Organizzazione Team, User Story, Backlog, e tutto ciò che ti serve per partire.

Scarica il post sulle alternative a Scrum

Iscriviti alla newsletter e scarica gratuitamente il post "Agile Scrum: Alternative più flessibili e agili"