Scrum è un framework leggero ed è caratterizzato da una serie di eventi che si ripetono nel corso di uno Sprint: Daily Scrum, Sprint Planning, Backlog Refinement, Sprint Review e Sprint Retrospective.
Uno Sprint, noto anche con il nome di iterazione, non è nient’altro che un periodo di tempo con lunghezza massima di un mese, all’interno del quale il team Scrum produce almeno un incremento di prodotto (o di software) potenzialmente rilasciabile.
Ogni Sprint inizia immediatamente in seguito al precedente, senza soluzione di continuità. E non esistono Sprint “speciali”, ovvero Sprint che non prevedono la consegna di valore per l’utente finale (come Sprint 0, Hardening Sprint, Release Sprint, Design Sprint, e altri fantomatici esempi).
Segui il link per una descrizione dettagliata su Scrum.
Andiamo ora a vedere come si collocano questi eventi all’interno di un tipico Sprint. E come un team collabora con il fine di produrre valore per l’utente finale.
Mentre leggi questo articolo, tieni però a mente che Scrum non è un metodo prescrittivo o un puro processo di project management.
Le modalità di esecuzione degli eventi, così come le pratiche di sviluppo e gli strumenti, sono spesso il risultato di un lavoro di ispezione e adattamento, in base al quale il team migliora continuamente i propri processi.
Ciò che segue è quindi soltanto a titolo di esempio e potrebbe variare a seconda dell’organizzazione o del team. Se sei una persona “visiva” più in basso puoi trovare un paio di immagini riassuntive.
Giorno 1: Sprint Planning
È il primo giorno dello Sprint: l’intero team Scrum si riunisce per pianificare l’iterazione che sta per iniziare. In una situazione ideale gli elementi in cima al Product Backlog dovrebbero già essere stati discussi in sede di Refinement durante lo Sprint precedente, ma nulla vieta di procedere con la pianificazione anche in caso ciò non fosse avvenuto.
Lo Sprint Planning si sviluppa intorno a tre argomenti:
- Perché questo Sprint è di valore
- Cosa può essere completato in questo Sprint
- Come verrà svolto il lavoro selezionato
Il timebox dello Sprint Planning è di 8 ore al massimo per uno Sprint di un mese. In Sprint più brevi, la durata può essere minore: quanto tempo dedicare è a discrezione del team.
Durante lo Sprint Planning, Product Owner e sviluppatori collaborano con il fine di identificare un obiettivo per lo Sprint (Sprint Goal), e per definire una soluzione attraverso la stesura dello Sprint Backlog.
Il Product Owner ha la responsabilità di spiegare come gli elementi in cima al backlog, quindi quelli più importanti e che sono verosimilmente pronti per essere pianificati, si relazionino al Product Goal, ovvero l’obiettivo a lungo termine del prodotto. Anche stakeholder ed esperti in materia possono partecipare alla riunione su invito del team, in caso di necessità.
Gli sviluppatori (i Developer) hanno invece il compito di creare la pianificazione vera e propria, in modo che entro il termine dello Sprint sia possibile rilasciare almeno un incremento di software (o di prodotto) potenzialmente rilasciabile, in linea con la Definition of Done.
Lo Scrum Master è molto probabilmente la persona che facilita il meeting, offrendo supporto al team in modo che la pianificazione e l’intera discussione avvenga in maniera efficace. Per esempio può suggerire tecniche per scomporre ulteriormente i Product Backlog Item o le User Story. Oppure fa scaturire conversazioni attraverso l’uso di domande mirate. O aiuta a mantenere il focus sullo Sprint Goal, eccetera…
Al termine dello Sprint Planning il team procede con il primo Daily Scrum dell’iterazione.
Gestire eventuali modifiche successive alla pianificazione
Lo Sprint Backlog creato dai Developer entro il termine della sessione di Sprint Planning non è un artefatto immutabile, a differenza dello Sprint Goal che invece rimarrà fisso per tutta la durata dell’iterazione.
Durante il corso dello Sprint gli sviluppatori hanno infatti l’autonomia e la flessibilità di riorganizzare il proprio lavoro autonomamente con il fine di raggiungere l’obiettivo stabilito in fase di pianificazione, aggiungendo o rimuovendo task agli elementi che compongono lo Sprint Backlog (i Product Backlog Items), o scomponendoli ulteriormente.
Detto ciò, Scrum è un framework collaborativo e la cosa più importante è il dialogo trasparente e continuo tra Product Owner e sviluppatori. Se in fase di svolgimento dello Sprint lo scope dello Sprint Backlog si rivelasse parzialmente o completamente diverso da quanto inizialmente pianificato, i Developer devono necessariamente rinegoziare e riconcordare lo scope con il Product Owner.
Approfondimento: Sprint Planning
Approfondimento: Domanda – Aggiungere lavoro allo Sprint
Tutti i giorni: Daily Scrum (o Daily Stand up)
Come dice il nome, il Daily Scrum è un evento che avviene quotidianamente. Ha una durata massima di 15 minuti, indipendentemente dalla dimensione del team, ed è una vera e propria mini sessione di pianificazione.
È un meeting obbligatorio per gli sviluppatori del team (i Developer) ma non per Product Owner e Scrum Master, che possono comunque assistere all’evento se lo desiderano. In ogni caso, lo Scrum Master ha la responsabilità di assicurarsi che il team abbia svolto il meeting (ma anche e soprattutto che il meeting abbia valore per il team), e viene solitamente coinvolto al termine della riunione in caso fosse necessario un supporto per la risoluzione degli impedimenti.
Non esiste una modalità standard per condurre il Daily Scrum. Il team è libero di trovare il formato che più si adatta alle proprie esigenze. L’importante è che il focus sia rivolto verso le attività necessarie al raggiungimento dello Sprint Goal.
Solitamente (o storicamente) il Daily si basa su tre domande a cui gli sviluppatori devono rispondere:
- Cosa ho fatto ieri?
- Cosa farò oggi?
- Quali impedimenti rallentano o bloccano i miei progressi?
Sentiti libero di esplorare e magari di trovare altri formati in grado di aumentare il coinvolgimento del team – e che somiglino di meno a un’interrogazione di quelle che ci davano gli incubi a scuola!
L’importanza del Daily per un team Scrum
Ma perché il Daily Scrum è un evento fondamentale? Quando si lavora con Agile e Scrum è importante partire dal presupposto che la pianificazione iniziale (quindi lo Sprint Planning), nonostante sia essenziale, è soltanto una proiezione. Questa proiezione evolve continuamente in base all’esperienza e alle lezioni apprese in fase di sviluppo, e se necessario va aggiornata in modo che rimanga rilevante per il raggiungimento dello Sprint Goal.
Questo approccio è noto come processo empirico o semplicemente empirismo. Si basa sui fatti, sull’esperienza e sull’osservazione della realtà, e si contrappone all’approccio predittivo in cui si cerca di pianificare tutto nei minimi dettagli, prima ancora di iniziare con il lavoro.
In un ambito complesso (vedi: Framework Cynefin) come lo sviluppo di prodotti e servizi, l’approccio empirico è l’unico in grado di garantire la soddisfazione dell’utente finale, attraverso un processo continuo di ispezione e adattamento.
Per il motivo che ho appena esposto, il Daily è uno degli eventi più importanti di Scrum: se sei uno Scrum Master o un Product Owner non trasformarlo in un meeting di status report. Fai in modo che sia un’occasione per gli sviluppatori di allinearsi e rivedere, quotidianamente, la propria pianificazione.
Approfondimento: Il Daily Scrum Meeting
Durante lo Sprint: Backlog Refinement
Nella guida di Scrum il Backlog Refinement è descritto come l’atto di scomporre il contenuto del Product Backlog in elementi più piccoli e precisi. È un’attività ricorrente che consiste nell’aggiungere dettagli come descrizione, ordine e stima a ciascun “Product Backlog Item”.
Per quanto riguarda le stime, una delle pratiche più utilizzate (pratiche che tuttavia non fanno parte del framework Scrum) è il Poker Planning.
Scrum non include il Refinement tra gli eventi ufficiali e non indica come debba essere svolto. Nella pratica di tutti i giorni è spesso un meeting ricorrente nel calendario del team, o un workshop verso il termine dello Sprint.
Tuttavia nulla vieta di considerare come attività di Refinement anche discussioni informali tra Product Owner e singoli Developer, laddove siano finalizzate alla definizione e all’aggiornamento del Product Backlog in preparazione dello Sprint Planning successivo.
Visto che non è un evento ufficiale, il Product Backlog Refinement non ha un timebox ben definito, e occupa solitamente una percentuale che va dal 5 al 10% della durata dell’iterazione. Ma può richiedere più o meno tempo, a seconda del team, del prodotto, o degli individui.
Come accennato in precedenza è un’attività che coinvolge principalmente Product Owner e Developer, ma anche stakeholder ed esperti in materia possono essere coinvolti nella discussione, se richiesto dallo Scrum team o qualora fosse necessario.
Lo Scrum Master solitamente non contribuisce in termine di contenuti , ma può aiutare a facilitare il Refinement qualora si svolgesse sotto forma di riunione o di workshop.
Quindi il Refinement è il momento per analizzare i requisiti?
Al contrario di quanto in molti credono, il Refinement non è una vera e propria attività di design e analisi approfondita in cui si cerca di anticipare problemi e soluzioni. È un’attività che serve piuttosto per verificare che esistano i presupposti, in termini di skill e di informazioni, per costruire “qualcosa” di valore che possa essere utilizzato fin da subito da stakeholder e utenti finali.
In parole povere, l’obiettivo è quello di ottenere abbastanza informazioni per poter considerare i Product Backlog Item in cima al Product Backlog “pronti” o “maturi” per l’iterazione successiva.
Approfondimento: Il Backlog Refinement
Collaborazione e dialogo continuo
Il team Scrum non lavora mai in isolamento. Anche quando non è impegnato in riunioni o in attività di Refinement, ciascun membro del team collabora e si aiuta a vicenda, quotidianamente. Il successo o il fallimento di uno Sprint non è mai colpa del singolo, ma dell’intero team.
Esempi di collaborazione possono includere: programmazione in coppia, mob programming (programmazione in gruppo), code review, chiedere e offrire aiuto, chiedere chiarimenti, condividere informazioni e conoscenze, mantenere il focus sullo Sprint Goal e sulla Definition of Done, sollevare impedimenti non appena si presentino, dialogare di persona anziché aprire “ticket” sui tool di project management, eccetera.
Per un ripasso sui valori e i principi agili: Manifesto per lo sviluppo agile di software
Termine dello Sprint: Sprint Review
Lo Sprint Review è un’occasione importante di ispezione e adattamento. Avviene al termine dello Sprint, e il suo scopo è quello di dimostrare e discutere il lavoro svolto durante l’iterazione.
A questo evento partecipa tutto il team Scrum ed è incoraggiata la partecipazione degli stakeholder chiave. Per uno Sprint di un mese, il timebox per lo Sprint Review è di 4 ore al massimo. Per Sprint più brevi può essere necessario meno tempo.
Il meeting è solitamente facilitato dallo Scrum Master, ma nulla vieta che qualsiasi altro membro del team, incluso il Product Owner, faciliti lo Sprint Review. Il format prevede spesso una demo delle funzionalità implementate, ma la cosa più importante è che ci sia spazio per una conversazione sul lavoro svolto in relazione allo Sprint Goal e sui progressi verso il raggiungimento del Product Goal.
Lo Sprint Review non dovrebbe quindi assomigliare a un meeting di chiusura del progetto stile waterfall, dove il Product Owner (o ancora peggio gli stakeholder) “approva” o “respinge” ciò che è stato dimostrato. Visto che Scrum promuove la collaborazione continua, a questo punto dello Sprint non dovrebbero esserci grosse sorprese o imprevisti. Per nessuno.
Il Review dovrebbe invece essere qualcosa a cui il team non vede l’ora di partecipare, un’occasione per verificare tutti insieme se ci si sta muovendo nella direzione giusta (il Product Goal) e per festeggiare i progressi. Per questo motivo la presenza degli stakeholder è molto importante: la discussione sul lavoro svolto può infatti generare nuove idee e nuove feature da aggiungere al Product Backlog, ma anche riflessioni su scenari futuri e su dinamiche di mercato, o impedimenti che devono essere risolti all’interno dell’organizzazione.
Approfondimento: Lo Sprint Review
Chiusura dello Sprint: Sprint Retrospective
L’ultima attività che conclude uno Sprint in Scrum è lo Sprint Retrospective. Mentre lo Sprint Review si concentra sul prodotto e sul valore generato per l’utente finale, il Retrospective ispeziona il processo e le dinamiche di gruppo. L’obiettivo è di migliorare continuamente e aumentare l’efficacia del team.
In uno Sprint di un mese la durata del Retrospective è di tre ore al massimo. In Sprint più brevi, la durata è minore: per esempio in un’iterazione di due settimane può essere sufficiente un’ora e mezza di tempo.
È richiesta la partecipazione di tutto lo Scrum team al Retrospective, quindi: Product Owner, Scrum Master e i Developer. Di solito è lo Scrum Master che facilita la riunione. Gli stakeholder e in genere qualsiasi persona esterna al team, come manager o chiunque sia in grado di esercitare pressione o influenzare le decisioni del gruppo, è esclusa da questo evento.
Il Retrospective deve essere un ambiente sicuro ed è fondamentale avere una discussione aperta e cercare di giungere alla radice di ciascun problema identificato.
Un’eccezione alla regola che esclude dal Retrospective persone esterne potrebbe avvenire nel caso in cui lo Scrum Master desiderasse partecipare attivamente alla discussione: in questo caso è consigliabile affidarsi a un facilitatore esterno al team, per esempio un altro Scrum Master o un Agile Coach.
Così come ogni altro evento in Scrum non esiste una modalità di esecuzione predefinita o raccomandata. In un tipico Retrospective solitamente ci si concentra su tre aspetti:
- Cosa è andato bene durante lo Sprint precedente
- Cosa possiamo migliorare
- Cosa ci impegniamo a migliorare nel prossimo Sprint
Esistono diverse tecniche di facilitazione per uno Sprint Retrospective ed è importante di tanto in tanto cambiare il formato, in base al contesto dello Sprint appena terminato o in modo da concentrarsi su aspetti diversi.
Un libro che ti consiglio vivamente di leggere, in caso volessi comprendere a fondo l’importanza del Retrospective, ma anche imparare tecniche nuove, è il seguente:
Improving Agile Retrospectives: Helping Teams Become More Efficient (purtroppo disponibile solo in inglese).
Non sottovalutare l’importanza del Retrospective
Nonostante lo Sprint Retrospective sia l’ultimo degli eventi di Scrum è a mio avviso il più importante di tutti, in quanto promuove la ricerca del miglioramento continuo grazie a un processo di ispezione e adattamento.
Se stai pensando di introdurre Scrum nella tua organizzazione, il Retrospective è il primo evento che ti consiglio di implementare!
Approfondimento: Lo Sprint Retrospective
Partecipazione agli eventi di Scrum
Per concludere ti lascio qui sopra un’immagine riassuntiva su come ciascun membro dello Scrum team sia chiamato a partecipare agli eventi che avvengono durante uno Sprint.
Partecipare a un evento significa contribuire attivamente alla discussione, sia dal punto di vista dei contenuti ma anche in termini di “facilitazione” dell’evento. Product Owner e Developer si confrontano quotidianamente sul “perché” e sul “come”, mentre lo Scrum Master il più delle volte facilita il dialogo e crea l’ambiente ideale per uno scambio costruttivo di idee.
A volte anche stakeholder ed esperti in materia partecipano attivamente agli eventi del team, come nel caso dello Sprint Review, del Refinement e più raramente dello Sprint Planning.
Ad ogni modo chiunque all’interno dell’organizzazione può “assistere” a questi eventi, visto che Scrum promuove trasparenza, a patto che non si creino interferenze con il lavoro e con l’autonomia del team. Esiste però un’eccezione importante: come detto in precedenza il Retrospective deve essere percepito come un ambiente sicuro e la presenza di persone esterne al team non è consigliata.
Infine ti invito a condividere una riflessione: qual è la tua esperienza con gli eventi di Scrum? Nella tua organizzazione vengono compresi fino in fondo, o vengono soltanto implementati come un “rituale” fine a se stesso, senza la comprensione del valore e del motivo per cui sono necessari?
È FINALMENTE DISPONIBILE IL VIDEOCORSO DI AGILE WAY!
CORSO APPROFONDITO SU SCRUM E SULLE METODOLOGIE AGILI
Aggiornato all’ultima versione della guida ufficiale di Scrum!
Più di 3,5 ore di video lezioni su Scrum, ideale per prepararsi a un esame di certificazione PSM I e per comprendere i valori, i principi e le pratiche dei metodi Agili. In questo corso imparerai:
- Origine, nascita e significato delle metodologie Agili
- Differenze tra Scrum e i modelli tradizionali
- Tutte le componenti del framework Scrum, i valori, le pratiche e le metriche
- Come gestire al meglio un progetto e un prodotto con Scrum
- Come mantenere un’attenzione continua al valore generato e al cliente
- Simulatore di esame di certificazione (80 domande)
- Tanto altro…
* Offerta limitata nel tempo
