Novembre 8, 2023 - di Giuseppe Romeo and Andrea Pacchioni
Come applicare le flow metrics ad uno Scrum Team: un case study
Come applicare le flow metrics ad uno Scrum Team? Nei due post precedenti dedicati a come usare le flow metrics per pianificare prima parte e seconda parte, noi – Giuseppe Romeo, Scrum Master @ Hudl e Andrea Pacchioni, Product Manager of Recruitment @ Wyscout – Hudl – vi avevamo promesso un case study ad hoc sul tema. Dunque, eccoci qui.
Ma partiamo dalle basi: Scrum è il framework Agile più diffuso (secondo il report VersionOne 2023 ha un tasso di adozione del 73% nelle società che fanno sviluppo agile), quindi è importante capire come applicare i concetti visti in uno Scrum Team.
Sì, perché la buona notizia è che i metodi visti si possono applicare senza alcuna incompatibilità col framework. È invece un mito che gli scrum team debbano usare approcci basati su story points, burndown charts o burnup charts per pianificare e aumentare la propria predicibilità. Abbiamo anzi visto negli articoli precedenti che questi approcci sono estremamente esposti a problemi come il flaw of averages e tendono a semplificare eccessivamente i problemi di forecast.
Vediamo, quindi, come possono cambiare i momenti più importanti della vita di uno Scrum Team secondo l’approccio a nostro giudizio più robusto, quello proposto principalmente da Daniel Vacanti e Will Seele. Questo articolo richiede un po’ di conoscenza di Scrum, noi ci limiteremo a rinfrescare qualche concetto.
Cosa vedremo in questo post:
Come applicare le flow metrics ad uno Scrum Team
Refinement
Il Refinement è l’atto di scomporre e definire ulteriormente gli elementi del Product Backlog in elementi più piccoli e precisi. È essenziale sia per creare uno shared understanding su come vogliamo incrementare e migliorare il prodotto, sia per definire strategie concrete di attuazione di queste idee.
Tipicamente, questo accade con lo sforzo collaborativo del team in incontri dedicati e/o nello Sprint Planning; le conversazioni diventano (se il team le adopera) User Stories, che si arricchiscono di dettagli (acceptance criteria, o esempi e regole se si segue un approccio BDD, dimensione, ordine) e, se sono “grandi”, si dividono a loro volta in altre User Stories o elementi più piccoli.
Le flow metrics ci guidano sia su quali elementi necessitino di Refinement prima di entrare in uno Sprint, sia su quando possiamo considerare il refinement sufficiente.
Ricordate il Service Level Expectation?
È il forecast di riferimento per il singolo Work Item che, in genere, viene scelto dal team guardando 85mo percentile del Cycle Time. La domanda che si può fare per capire se il nostro elemento del backlog è raffinato a sufficienza e dunque lavorabile è: ne sappiamo abbastanza da completare realisticamente questo Elemento entro il nostro SLE? (potete sostituire all’avverbio “realisticamente” la probabilità scelta per l’SLE, es. “con probabilità dell’85%”).
- Se la risposta è no – serve più attività di Refinement, vanno aggiunte informazioni o l’elemento va meglio suddiviso;
- Se la risposta è sì -possiamo fermarci qui, ulteriore tempo speso potrebbe diventare wasteful.
Questo approccio al sizing che, notate bene, usa il Cycle Time e non l’effort, è chiamato anche “Right Sizing” perché permette di identificare gli elementi della dimensione “giusta” per il nostro sistema produttivo.
Altra nota: in uno Scrum Team sano, il SLE non potrà essere superiore alla durata dello Sprint (la mia esperienza è che meno della metà della sua durata va bene).
Sprint Planning
Lo Sprint non è altro che un timebox di un certo numero di giorni, facciamo ad esempio 14, entro cui si portano avanti sia attività tutte le attività legate al prodotto, dalla strategia, alla discovery alla delivery.
E lato delivery, ogni Sprint dovrebbe portare ad un incremento di prodotto usabile e che rispetti le metriche di qualità definite. Durante l’incontro di Sprint Planning si stabilisce, tra l’altro, l’obiettivo dello Sprint e quali elementi del backlog pianificare per arrivare a quell’obiettivo.
Il ruolo delle flow metrics qui è di permettere la creazione di Sprint Forecast (propriamente detti) che ci consentano di selezionare quanti elementi vogliamo pianificare per lo Sprint.
È quindi propriamente il caso di un batch di Work Item, in cui si applicano le simulazioni di Monte Carlo.
Nell’esempio la simulazione da fare è: quanti elementi riusciremo a fare in 14 giorni?
Data la distribuzione di probabilità degli esiti della simulazione, potremo scegliere quanto rischio prendere nella pianificazione, ad esempio potrebbe andar bene scegliere di selezionare 10 Elementi con una probabilità di completamento del batch del 70%. Ma se il team per qualche motivo si sentisse più confidente (es. un nuovo approccio al testing più veloce) e non ci fossero deadline cruciali, potremmo accontentarci di una probabilità inferiore.
Chiaramente, gli elementi selezionati devono essere tutti Right Sized, per il forecast va scelto un intervallo di throughput che riteniamo rappresentativo (ragionevolmente il team avrà una performance simile all’intervallo storico selezionato) e il team deve essere in condizioni di stabilità.
Daily Scrum
Il Daily Scrum è il breve incontro giornaliero che serve ad uno Scrum Team per definire o adattare il piano del giorno per raggiungere più efficacemente l’obiettivo dello Sprint.
Questo è il meeting più appropriato per le azioni giornaliere di controllo del flusso e quindi della stabilità del sistema team che abbiamo visto nel precedente articolo.
In particolare, guardare l’età dei Work Item, le nostre soglie di intervento, e agire quando gli Item stanno per diventare anomali perché insolitamente vecchi o troppo vicini a superare il nostro SLE.
Sprint Review
La Sprint Review serve ad ispezionare il risultato dello sprint al fine di adattarsi e avanzare verso lo stato desiderato del Prodotto, in collaborazione con gli Stakeholder. Visto che si parla anche di futuro, i forecast di Monte Carlo possono eventualmente aiutare nella discussione. Ad esempio mostrare le probabilità aggiornate sulla delivery (simulazioni “quando finiremo il batch di item”) del nostro MVP potrebbe aiutare a ri-prioritizzare alcuni aspetti e tralasciarne altri. Il continuous forecasting aiuta l’audience a tenere sempre una posizione realistica e aggiornata nella discussione.
Sprint Retrospective
Le retrospettive sono il cuore del continuous improvement del team, l’incontro che analizza lo Sprint passato per trovare modi di diventare più efficaci e produrre migliore qualità.
Ci sono molte ricette per portarle avanti e un’ottima pratica è scegliere il formato che più si ritiene adatto allo Sprint trascorso, ma sicuramente un approccio data oriented può essere spesso utile.
Avere davanti le flow metrics dello sprint (es. throughput, anomalie di Cycle time, il nuovo SLE risultante dai dati, il daily Work In Progress …), durante una Retrospective può portare a fare ragionamenti e miglioramenti sul flusso di lavoro del team di grande impatto.
Come applicare le flow metrics ad uno Scrum Team: un case study
In conclusione, vi presentiamo un caso concreto, lo Scrum Team di cui siamo fieramente parte.
Parentesi da Scrum Master dello Scrum Master. Il self-management è alla base di uno Scrum Team di successo. La motivazione che trova un team nel perseguire i suoi obiettivi quando ha la possibilità di agire in autonomia sulla sua organizzazione e su come raggiungerli è impareggiabile. Questo richiede una gestione del prodotto basata sugli outcome, che libera creatività del team su come raggiungerli, e un’organizzazione del teamwork e della delivery basata su esperimenti, decisi dal team, di cui si misura l’efficacia.
Nel nostro caso studio, mentre il Product Manager (con l’accountability di Product Owner in Scrum) si occupava di rendere vera la prima parte sugli outcome (chiaramente col nostro pieno supporto) ci siamo occupati di rendere vera la seconda, col suo pieno supporto.
Ci siamo, quindi, limitati a presentare l’approccio con dei Workshop a tema, a mostrare i dati raccolti durante gli Sprint, qualche commento qua e là, e il team ha trovato la sua strada, sperimentando, principalmente con azioni decise durante la Sprint Retrospective.
Il nostro Right Sizing
Sicuramente starete pensando che il team in questione non usi gli Story Points, che più volte abbiamo citato come strumento inaffidabile. E invece no.
Il team partiva da una situazione in cui usava gli story point ma questi non garantivano la predicibilità degli sprint. C’era la sensazione che qualcosa non andasse, ma non se la sentivano di passare ad un approccio così diverso.
La strada scelta dal team è stata quella di raffinare ulteriormente tutto quello che superava i 5 Story Points: la barriera di ingresso, invece di essere espressa in termini di SLE (di tempo), era questo numero arbitrario 5 rappresentante l’effort del Work Item. La right size è 5 o meno di 5.
Con sorpresa, funzionò. Il motivo era nei dati. Guardando il grafico di correlazione tra Story Points e Cycle Time praticamente dire “5 Story points” voleva dire “5 giorni o meno” perchè la maggior parte degli item valutati entro 5 story points finivano in quel range.
Implicitamente quindi il team aveva scelto un SLE di 5 giorni di calendario e si era prefisso di raggiungerlo. Dopo un po’ di iterazioni, l’SLE del team si è stabilizzato effettivamente su 5 giorni, e adesso usiamo “entro 5 giorni di calendario” o “entro 5 story points” intercambiabilmente.
Il nostro Daily Scrum
Il nostro daily si tiene in remote call (è un team distribuito) visualizzando la scrum board in un tool di ticketing. Dopo essermi unito al team come Scrum Master, quasi subito il team ha deciso di darci una piccola parentesi del daily scrum in cui mettere in evidenza i punti che riteniamo rilevanti per il flusso di delivery.
Siamo passati gradualmente dai burn down chart all’analisi dell’età dei Work Item, che calcolavamo a parte, il che equivaleva di solito a parlare dei più vecchi. Adesso le nostre card si olorano diversamente a seconda della loro età e di quanto si avvicinano ai nostri percentili di intervento e il team analizza le anomalie in autonomia. E la discussione si è estesa anche ad anomalie di WIP.
La stabilizzazione del team e i forecast
Dopo pochi sprint in cui facevamo attenzione a quello che stava succedendo in termini di flusso, monitorando e raffinando i Work Item, il team è effettivamente riuscito a mantenere un 85mo percentile stabilmente intorno ai 5 giorni.
Nella figura mostro questo forecast di riferimento (SLE calcolato ad ogni fine sprint usando come dati i Cycle Time dei 28 giorni precedenti) che si assesta dopo un periodo di instabilità.
L’impatto della stabilizzazione sul batch forecasting è l’immediata conseguenza. Usando esclusivamente i dati di throughput riusciamo a prevedere il numero di item che completiamo nello sprint entro un buon range di probabilità.
A fini di chiarimento, nelle immagini riportiamo un esempio. Le simulazioni che indicavano fosse realistico aspettarsi nello Sprint 7 il completamento di almeno 20 Work Item con il 70% di probabilità. Cosa che è poi avvenuta (siamo arrivati a 22 WI).
Osserviamo che i dati di forecast sono usati dal team per informare i planning, insieme ai dati storici di throughput, delle assenze programmate e persino il totale degli story points, per decidere il contenuto dello Sprint. La decisione non è quindi automatica, il team fa le sue considerazioni di ragionevolezza perché non si tratta di risolvere un problema matematico.
Abbiamo usato un foglio di calcolo per le simulazioni di Monte Carlo, esistono dei tool già pronti per farlo ma non erano a disposizione del team. Se inizialmente può essere più faticoso è un approccio che comunque consigliamo per approfondire maggiormente come funzionano questi algoritmi.
Effetti collaterali
La stabilizzazione del team dal punto di vista dei cicli di delivery ha portato a numerosi “effetti collaterali”.
Il principale dal un punto di vista motivazionale: la riduzione dello stress della delivery. La stabilizzazione verso un ritmo sostenibile ha portato a facce più sorridenti, a più collaborazione “gioiosa” e creativa durante i nostri incontri.
Inoltre, la tendenza alla riduzione dei cycle time ci ha portato a completare il lavoro “prima”, accorciando i cicli di feedback, con la conseguente soddisfazione derivante da un percepito aumento di produttività.
Il fatto di aiutarsi a vicenda per rispettare i SLE ha portato ad un aumento di collaborazione e condivisione di competenza. E di accountability: ognuno porta avanti responsabilmente la sua parte del lavoro e si interessa a quello degli altri.
Anche il workflow stesso è stato migliorato per supportare meglio i nuovi ritmi e collaborazione (nuove policy per considerare il lavoro “done”, nuove policy per andare in produzione, nuove policy di test…).
E ovviamente ci sono stakeholder più soddisfatti, che possono vedere il prodotto crescere costantemente e non a singhiozzo, ed esperimenti più rapidi che guidano la strada.
Tra gli effetti collaterali “curiosi”, riportiamo anche che i grafici più tradizionali come lo Sprint burn-down o le “velocity chart”: tutti hanno avuto un deciso miglioramento per il fatto di essersi concentrati sulle flow metrics.
Ringraziamenti
Come avrete capito dal caso studio, avevamo il supporto di un team orientato al miglioramento continuo, desideroso di sperimentare. Durante questo viaggio verso gli outcome di prodotto, aiutati dalle flow metrics, siamo diventati sempre più affiatati, entusiastici e creativi, spingendoci a vicenda, quasi inconsapevolmente, verso l’high performance.
È un piacere e un orgoglio lavorare con l’Arkham squad di Hudl, per cui nostri più grandi ringraziamenti vanno a loro, senza i quali questa serie di articoli non sarebbe stata possibile.
Grazie ad Antonio Arvigo, Mikarla Dael, Andrea De Gaetano, Filippo Maria Di Manno, Sakshi Pawar, Marco Piscera.
Work Cited – Daniel, Vacanti, and Will Seele. Flow Metrics for Scrum Teams. LeanPub, 2023-10-05.
Per non perdere nessuno dei nostri contenuti, iscriviti alla newsletter di Product Heroes!
