Lo scorso 25/02 la Agile Community di Torino ha ripreso con i meetup da remoto.
In quest’occasione abbiamo parlato di metriche – “Metriche – Dimmi, cosa misuri?”.
Più di 20 i partecipanti che hanno collaborato attivamente nel proporre metriche con l’ausilio di una board di Miro. Mediante una fase di voting abbiamo selezionato quelle più interessanti e avviato un dibattito sulle top 3.
Un grazie speciale ai nostri facilitatori Marcello Testi e Nicola Lobusto che ci hanno condotto attraverso una breve descrizione teorica verso l’attività pratica battendo il tempo in ogni step.
Che cosa mi porto a casa?
Metrica “buffer” – percentuale di tempo riservato ad attività che, per la loro alta priorità, possono entrare a far parte dello Sprint backlog anche dopo il suo inizio. Dal punto di vista di Scrum puro, la modifica del backlog non è permessa, ma sicuramente è stato interessante domandarsi:
- In alcuni ambiti di business, questa variazione è necessaria per ottimizzare il valore rilasciato?
- Analizzando gli Sprint precedenti è stato possibile capire se la presenza del buffer inficia le performance del team? Se sì come? Esiste un valore ottimale?
- L’introduzione di questo disturbo continuo nel product backlog, quanto permette al product owner di ottimizzare le attività?
- È necessario indurre più riunioni per singolo Sprint per analizzare queste eccezioni?
- Cosa succede se si è previsto un 30% di attività di buffer e poi gli imprevisti non arrivano? Quel tempo “prenotato ma mai usato” va gestito comunque con altre attività?
Metrica Lead Time – è il tempo che intercorre tra il momento in cui un cliente evidenzia una necessità e il momento in cui la soluzione viene rilasciata. Invece il Cycle time è il tempo trascorso da quando un’attività viene presa in carico da un membro del team fino a quando questa passa nello stato Done. Normalmente queste metriche vengono utilizzate in un contesto Kanban con attività che hanno una “grandezza” simile tra di loro. Ogni attività viene associata ad una classe di servizio che rappresenta la priorità con la quale quell’attività deve entrare nel backlog. Il Lead Time viene misurato per ogni classe in modo che possa essere compatibile.
Il concetto che c’è dietro è “quanto è vecchio un item”? Questa domanda mi ha aperto un mondo: quanto feedback diamo ai nostri utenti finali sul valore delle loro richieste e sul fatto che sicuramente non tutte saranno realizzate? Soprattutto quando ci sono più stakeholder? Uno stakeholder magari può pensare che non prendiamo in considerazione le sue proposte, per lui importantissime ed urgentissime, perché queste non raggiungono mai la parte superiore del product backlog. Come gestire questo fenomeno?
Metrica story point – numero di story point realizzate durante uno Sprint. Qual è la relazione tra questa misura e il tempo? Un suggerimento per cominciare ad introdurre le SP nel team è quello di dare un range di misura concordato con il team. Ad esempio: 1 SP equivale a 2-4 ore di lavoro. L’altro aspetto importante riguarda quanto siamo in grado di scomporre le attività in modo che siano facilmente misurabili in SP. Siamo in grado di identificare le attività troppo grandi o con alta incertezza per dare un valore di complessità certo? Uno spunto è l’utilizzo delle Spike (timebox dedicato ad esplorare una User Story).
Per concludere, vi invito a partecipare ai meetup delle diverse community.
I meetup sono sempre stati per me momenti divertenti e istruttivi, non vedo l’ora di scoprire di cosa tratterà il prossimo incontro!
(Questo articolo è stato originariamente pubblicato da Alma Maria del Campo Vara su Linkedin)
