Cosa succede in uno Sprint e quando?

L’implementazione di successo di Scrum comprende una serie di cerimonie importanti. Tra queste ci sono lo Sprint Planning, lo Sprint Review, il Daily Scrum, la Sprint Retrospective e molto altro.

Spesso ci sono incertezze su chi dovrebbe partecipare a quali cerimonie Scrum, quando si svolgono, quanto dovrebbero durare, qual è l’obiettivo della rispettiva cerimonia ecc.

In questo articolo cerchiamo di chiarire queste incertezze:

Lo Sprint Planning

Quando inizia lo Sprint, viene anche condotto lo Sprint Planning. Segna quindi ufficialmente l’inizio dello Sprint.

L’intero Scrum Team partecipa allo Sprint Planning; cioè sia il team di sviluppo che lo Scrum Master e il Product Owner. Anche altre persone possono, in rari casi, partecipare a questo evento, se Product Owner e team di sviluppo lo ritengono opportuno. Se ad esempio nel prossimo Sprint deve essere sviluppata una funzionalità che viene spiegata meglio da un esperto della materia (che non è contemporaneamente il Product Owner), può essere utile che questa persona sia presente al Planning. Nella maggior parte dei casi è però più sensato che queste discussioni avvengano al di fuori del Planning Meeting vero e proprio.

La durata dello Sprint Planning è proporzionale alla durata dello Sprint. Per uno Sprint di quattro settimane il Planning non dovrebbe durare più di otto ore; per uno Sprint di una settimana non più di due ore – quindi max. due ore per settimana di Sprint.

Questa limitazione a una durata massima di un meeting si chiama anche Time Boxing. Raccomando ai team di cercare di concludere lo Sprint Planning in circa la metà del Time Box massimo consentito.

Come input per lo Sprint Planning, lo Scrum Master porta informazioni sulla Velocity (velocità di lavoro) media e attuale. Il Product Owner porta il Product Backlog o almeno i Backlog Item con la priorità più alta al Planning. In alcuni team il Product Owner presenta già al Planning un Sprint Goal preliminare, che viene poi rielaborato insieme al team durante il Planning.

Il risultato dello Sprint Planning è un team più informato e meglio preparato per i lavori in arrivo. Ulteriori risultati del Planning sono lo Sprint Backlog e uno Sprint Goal creato collaborativamente.

Daily Scrum / Daily Standup

Il Daily Scrum – chiamato anche Daily Standup – è una breve cerimonia che si svolge quotidianamente e nella quale i membri del team si sincronizzano riguardo al loro lavoro. Con i Daily Scrum si assicura che le persone giuste lavorino sulle cose giuste al momento giusto.

Ogni giorno ogni membro del team risponde alle seguenti tre domande:

1. Cosa ho fatto ieri per raggiungere lo Sprint Goal?

2. Cosa farò oggi per raggiungere lo Sprint Goal?

3. Ho impedimenti/problemi che mi ostacolano, e se sì quali?

Queste domande possono essere formulate in modi diversi. Alcuni team preferiscono descrivere cosa hanno raggiunto piuttosto che cosa hanno fatto.

Partecipanti dovrebbero essere lo Scrum Master, il team di sviluppo e, a mio avviso, anche il Product Owner.

Nella community Scrum ci sono alcune discussioni sul fatto che il Product Owner debba o meno partecipare al Daily Scrum. Non permettere al Product Owner di partecipare al Daily Standup può separarlo troppo dal team. Un sentimento “noi-contro-gli-altri” esiste già in troppe organizzazioni. Non riesco a immaginare perché un Scrum Team o il suo Product Owner vorrebbe rafforzare ulteriormente questo atteggiamento negativo.

I Daily Scrum sono limitati a una durata massima di 15 minuti. L’obiettivo del Daily Scrum è una breve sincronizzazione del team. A differenza dello Sprint Planning, qui non raccomando di finire già nella metà del tempo previsto. Per la maggior parte dei team 5-7 minuti semplicemente non bastano per affrontare problemi reali o capire quali lavori sono stati completati. Se i Daily Scrum vengono accorciati troppo, diventano rapidamente routine con affermazioni come “Ieri ho fatto XY. Oggi faccio questo e quello. Non ho impedimenti.”

Non ci sono risultati formali dei Daily Scrum, oltre al coordinamento migliorato dei lavori nel team di sviluppo.

Sprint Review

Lo Sprint Review si svolge nell’ultimo giorno dello Sprint. Product Owner, Scrum Master e team di sviluppo dovrebbero essere presenti, così come i rispettivi stakeholder. Quali stakeholder debbano essere presenti cambia da Sprint a Sprint e dipende da ciò che è stato consegnato nello Sprint.

Lo Sprint Review ha un Time Box di massimo quattro ore per uno Sprint di quattro settimane. Corrispondentemente più brevi sono i Time Box per Sprint più corti, ad es. un’ora per uno Sprint di una settimana.

Nello Sprint Review devono essere mostrati tutti i Product Backlog Item che corrispondono alla Definition of Done. Questo significa che non vengono mostrati lavori ancora in corso, cioè non ancora completati. A volte può naturalmente essere sensato fare un’eccezione a questa regola.

La dimostrazione delle funzionalità completate è l’attività centrale di un tipico Sprint Review Meeting. La maggior parte dei team si prende però anche del tempo per discutere progressi ed eventuali problemi.

L’obiettivo del Review Meeting è raccogliere feedback sulle cose sviluppate durante lo Sprint. Il Product Owner raccoglie tutti i feedback e, se necessario, può adattare il Product Backlog in base a questi. Il risultato di uno Sprint Review è quindi un Product Backlog revisionato.

Sprint Retrospective

Nella Sprint Retrospective i membri del team hanno l’opportunità di riflettere su come migliorare il loro modo di lavorare. Questo può significare, ad esempio, che vogliano cambiare il modo in cui implementano Scrum e ad esempio adattare la durata dello Sprint. La Retrospective può però coprire anche aspetti generali della collaborazione, come non programmare più meeting al mattino o stabilire quali temi si possono discutere su Slack e quali vanno chiariti in una conversazione personale.

Alla Sprint Retrospective dovrebbe partecipare l’intero team – cioè il team di sviluppo, lo Scrum Master e il Product Owner. Qualsiasi altra cosa porterebbe solo a una spaccatura nel team. Un buon team agile dovrebbe evitare qualsiasi comportamento che porti a un mindset “noi-contro-gli-altri”.

Oltre alla volontà di migliorare, la Sprint Retrospective non richiede nessun altro input. Il risultato della Retrospective dovrebbe essere una lista di modifiche o proposte di miglioramento che il team vuole implementare.

Il Time Box per una Retrospective è di max. 3 ore. Di tanto in tanto può capitare che duri un po’ di più, ma nella maggior parte dei casi i team finiscono in meno di un’ora.

Product Backlog Refinement

Il Product Backlog Refinement serve a garantire che gli item in cima al Backlog siano pronti per il prossimo Sprint. Questo può significare aggiungere dettagli a item esistenti, fare stime, rimuovere certi item, riordinare le priorità, suddividere Backlog Item in item più piccoli o crearne di nuovi.

Anche se il Refinement del Backlog in sé è necessario, non significa che un team debba farlo come cerimonia ufficiale o che debba essere fatto in ogni Sprint. La maggior parte dei team conduce però regolarmente meeting di Backlog Refinement, tipicamente una volta per Sprint o a settimana.

Una buona linea guida è che un team non dovrebbe dedicare più del 10% del suo tempo complessivamente disponibile al Backlog Refinement – sia nel meeting stesso che nelle discussioni successive che ne derivano.

Nella maggior parte dei team partecipano ai meeting sia tutti i membri del team di sviluppo che il Product Owner e lo Scrum Master. A meno che un team non stia stimando i Product Backlog Item nei suoi meeting di Refinement, penso che circa la metà o due terzi dello sforzo di sviluppo siano sufficienti e il meeting possa così essere tenuto il più breve possibile per il team.

L’unica cosa che deve essere portata al Refinement sono gli item in cima al Product Backlog. I risultati del Refinement sono Product Backlog Item più piccoli, più adatti per il prossimo Sprint, e una migliore comprensione di alcuni Product Backlog Item.

Stima del Backlog

Come già menzionato sopra, molti team stimano i loro Product Backlog Item già durante il meeting di Refinement. Questa è la situazione ideale e se possibile l’intero team di sviluppo partecipa al Backlog Refinement.

Se solo una parte del team partecipa al Refinement, i membri del team si incontrano una volta per Sprint per stimare tutti i nuovi lavori per cui il Product Owner necessita di una stima.

Nella maggior parte dei team questi meeting di stima dovrebbero essere tenuti molto brevi. I team non dovrebbero né generare troppi nuovi Product Backlog Item né ricevere un’ondata di nuovi item dall’esterno. I lavori da stimare dovrebbero essere o molto importanti o item nuovi o esistenti che sono stati suddivisi per adattarsi meglio allo Sprint imminente.

Preferisco condurre il Product Backlog Estimating subito dopo un Daily Scrum e qualche giorno prima della fine dello Sprint. È abbastanza tardi perché la maggior parte dei nuovi item sia già stata identificata, e abbastanza presto perché il Product Owner possa cambiare la prioritizzazione in base alle nuove informazioni dalle stime.

Non raccomando di stimare gli item durante lo Sprint Planning. A quel punto è troppo tardi perché il Product Owner possa adattare la prioritizzazione in base alle stime. Inoltre porta i membri del team a dedicare più tempo alle stime di quanto dovrebbero. Quindi, non fare le stime dei Product Backlog Item durante lo Sprint Planning.

Prioritizzazione

Prima che inizi un nuovo Sprint, il Product Owner si assicura che tutti gli item in cima al Product Backlog siano stati prioritizzati. Secondo l’Oxford American Dictionary, prioritizzare significa: “Mettere compiti, problemi ecc. in ordine di importanza in modo da potersi occupare prima di quelli più importanti.”

Ciò significa che non basta dire: “Sono tutti necessari.” O come un Product Owner mi ha detto una volta: “Non si chiamano requisiti per niente; sono richiesti.”

Nella maggior parte dei casi non ci sarà una cerimonia ufficiale per la prioritizzazione. È piuttosto qualcosa che il Product Owner fa da solo dopo le conversazioni con gli stakeholder per chiarire le loro esigenze e desideri.

La prioritizzazione dovrebbe avvenire il più tardi possibile nello Sprint, ma in ogni caso dovrebbe essere completata prima del prossimo Sprint. Questo spesso può significare che viene effettuata in uno degli ultimi due giorni dello Sprint.

La prioritizzazione normalmente non richiede molto tempo, poiché il Product Owner tipicamente fa gli ultimi ritocchi nel corso dello Sprint in base a nuove intuizioni, piuttosto che prioritizzare tutto il Backlog in dettaglio fin dall’inizio.

I meeting in uno Sprint

Come potete vedere, ci sono una serie di cerimonie importanti in Scrum che dovrebbero essere condotte con cura. Speriamo che questo articolo vi abbia dato una migliore panoramica e vi abbia aiutato a ottenere più chiarezza nella quotidianità con il vostro Scrum Team. Se volete saperne di più, i nostri Training Scrum sono esattamente ciò che fa per voi.

Questo articolo proviene dal blog di Mike Cohn ed è stato da noi tradotto in italiano.