Sprint Planning Meeting

Il kick-off di ogni Sprint è lo Sprint Planning Meeting. Serve a definire il carico di lavoro del team Scrum per lo Sprint in arrivo. Come lo Sprint Planning Meeting debba essere preparato dal Product Owner, chi vi partecipa, qual è il processo e a cosa il team dovrebbe prestare attenzione, puoi leggerlo in questo articolo.

Sprint Planning: obiettivi e partecipanti del meeting

Uno Sprint Planning Meeting ha due obiettivi. Dopo uno Sprint Planning riuscito:

• il Product Owner e il team di sviluppo concordano sullo Sprint Goal (outcome)
• e hanno formato lo Sprint Backlog. Lo Sprint Backlog contiene tutti i Product Backlog Item che devono essere implementati nello Sprint per raggiungere lo Sprint Goal (output).

In alcuni contesti, Outcome e Output vengono anche riassunti come MVP, il Minimum Viable Product.

Chi invita allo Sprint Planning?

Il Product Owner invita il team di sviluppo e lo Scrum Master alla sessione di Scrum Planning. Se ci sono anche stakeholder che vogliono vedere qual è lo Sprint Goal e su quali Backlog Item si sta lavorando, il Product Owner invita anche loro.

Preparazione dello Scrum Planning Meeting

Affinché il Product Owner e il team di sviluppo raggiungano i due obiettivi del Planning Meeting, devono essere soddisfatti alcuni prerequisiti. I seguenti passaggi preparatori sono quindi essenziali prima dello Sprint Planning in Scrum. Se lavori tu stesso come PO o ti stai preparando per il ruolo di Product Owner, puoi usare questa checklist o gli elementi elencati di seguito.

• Il Product Owner ha definito uno Sprint Goal (Outcome) e selezionato i Product Backlog Item (PBI) associati.
• I PBI selezionati sono stati formulati con sufficiente dettaglio - preferibilmente in collaborazione con il team di sviluppo, ad es. nell’ambito di un Product Backlog Refinement.
• I PBI selezionati sono stati messi in un ordine secondo cui il team di sviluppo li lavorerà. Questo tiene conto delle dipendenze tecniche.
• Il team ha una Definition of Done (DoD). Questa fornisce una comprensione comune di “quando qualcosa è fatto”.
• La capacità del team per il prossimo Sprint è stata determinata, ad es. tenendo conto della Velocity media degli ultimi Sprint e di eventuali ferie pianificate dei singoli membri del team.

Il processo dello Sprint Planning

Una volta che lo Sprint Planning è preparato come descritto, puoi passare al processo vero e proprio con il tuo Scrum Team. Il meeting procede secondo la seguente agenda dello Sprint Planning:

• Il Product Owner presenta lo Sprint Goal e i PBI associati e risponde alle domande di comprensione del team. Lo Sprint Goal dovrebbe essere documentato nello Sprint Backlog in modo facilmente leggibile per tutti i membri del team.
• Se i PBI non sono ancora stati stimati, dovresti fare la stima adesso. Se la stima è già avvenuta, il tuo team può ora affinare la stima dopo la discussione dettagliata sull’implementazione.
• Il team fa una previsione al Product Owner e agli stakeholder su quali PBI consegnerà alla fine dello Sprint secondo la DoD scritta collaborativamente. In questo modo si forma lo Sprint Backlog, in cui dovrebbe essere documentato a quali PBI il team di sviluppo si è impegnato e su quali lavorerà opzionalmente in aggiunta.

Naturalmente, in Scrum c’è anche un timebox per lo Sprint Planning: la durata di uno Sprint Planning non dovrebbe essere superiore a un giorno (timebox: 8 ore).

Differenziazione in Sprint Planning 1 e 2

Il nostro consiglio pratico: i team Scrum spesso distinguono tra Sprint Planning 1 e 2:

• Lo Sprint Planning 1 si occupa della domanda: cosa vogliamo affrontare nel prossimo Sprint?
• Lo Sprint Planning 2 si occupa della domanda: come vogliamo affrontarlo?

A proposito, il timebox di entrambi i planning non è diviso in 4 ore ciascuno - invece, il Planning 1 è automaticamente piuttosto breve dopo un buon Refinement, mentre la parte più ampia del timebox è necessaria per il Planning 2.

Sebbene non sia obbligatorio, alcuni team di sviluppo suddividono i Product Backlog Item in pacchetti di lavoro più piccoli (task) nello Scrum Sprint Planning 2. Questa seconda parte dello Sprint Planning avviene spesso senza il Product Owner.

Cos’altro dovrebbe considerare un team nella pianificazione di uno Sprint?

Un team di sviluppo non sarà mai in grado di lavorare esclusivamente sugli Sprint Backlog Item selezionati in uno Sprint, perché in ogni ambiente di lavoro agile ci sono interruzioni, piccole emergenze e richieste di supporto urgenti nel frattempo.

Per questo motivo, per il tuo team è utile pianificare una sorta di buffer negli Sprint, che consenta ad esempio le seguenti attività:

• Risolvere problemi operativi, come quando un server va giù.
• Correggere bug critici
• Supporto tecnico di primo o secondo livello

Tali buffer assicurano che lo Sprint Planning Scrum produca un Backlog che il team può effettivamente realizzare senza frustrazioni dovute a problemi imprevisti. Inoltre, i nostri studi mostrano che i team con un buffer diventano più performanti nel tempo. Questo è dovuto in parte al fatto che questi team hanno maggiori probabilità di raggiungere i loro Sprint Goal, e quindi hanno più frequentemente sensazioni di successo.

I risultati dello Sprint Planning

Se tu e il tuo team potete segnare i seguenti punti come fatti, sapete che il vostro Sprint Planning è stato un successo e avete fatto tutto correttamente:

• Lo Scrum Team ha sviluppato una comprensione condivisa di ciò che deve essere realizzato nel prossimo Sprint (Sprint Goal).
• Attraverso la discussione del team di sviluppo tra di loro, avete una comprensione comune di come ogni PBI dovrebbe essere implementato.
• Avete creato uno Sprint Backlog ben strutturato che contiene i PBI nell’ordine del Product Backlog, eventualmente anche dopo un Task Breakdown con le attività associate.

Il più grande errore nello Sprint Planning Meeting

Alcuni team di sviluppo si perdono nel creare lo Sprint Backlog perfetto cercando di identificare e stimare meticolosamente ogni task, per quanto piccolo. Di solito questo accade quando il management non ha ancora compreso appieno il modo di lavorare agile e richiede stime così “esatte”.

Poiché si perde troppo tempo nello Sprint Planning Meeting se la stima è eccessivamente accurata, lo Scrum Master dovrebbe assicurarsi che l’obiettivo reale del planning non venga perso: ovvero selezionare i PBI giusti per il prossimo Sprint e parlarne quel tanto che basta affinché il team si senta pronto a lavorare sugli item.

Riepilogo dello Sprint Planning Meeting

Uno Sprint Planning Meeting di successo dipende da una buona preparazione come il Product Backlog Refinement. Lo Sprint Planning Meeting a sua volta fornisce il prerequisito che tutti nel team sappiano cosa deve essere implementato nel prossimo Sprint e come. Se lo Sprint deve avere successo e il team di sviluppo deve lavorare sui PBI con successo e senza frustrazione, il Planning Meeting è assolutamente indispensabile in Scrum.

Diventa un Certified Scrum Master

=> Dai un’occhiata alla nostra offerta di Training Scrum Master!

Dynamic Reteaming

=> Coaching dei team attraverso il cambiamento

Scaling Agile

=> Scopri come puoi scalare i tuoi approcci agili.