Sprint Planning:
cos’è e come farlo efficacemente

Mai come ora, ai team IT e di sviluppo sono richieste non solo capacità di reazione e risposta, ma anche e soprattutto rapidità ed efficacia di azione.

Implementare metodologie Agile come Scrum contribuisce a velocizzare le fasi di progettazione del software e, al tempo stesso, ad elevare la sua qualità.
La metodologia Scrum potenzia il processo di creazione del software attraverso un modello iterativo e progressivo, caratterizzato da una collaborazione intensa fra gli sviluppatori e i portatori di interesse.

Cerchiamo di capire di cosa si tratti, focalizzandoci su un aspetto specifico: lo Sprint Planning.

Cos'è lo Sprint Planning

Per cominciare, è opportuno un breve cenno su cosa sia Scrum, e come Sprint e Sprint Planning entrino in questo framework.

Creato e sviluppato da Ken Schwaber e Jeff Sutherland nel 1995, Scrum è un framework utilizzato dai team per organizzarsi autonomamente e mirare ad un obiettivo comune, enfatizzando la consegna efficiente del progetto attraverso riunioni, strumenti e ruoli specifici.

Simile ad una squadra sportiva che si prepara per una partita, Scrum promuove l’autogestione, l’apprendimento dall’esperienza, e l’adattabilità ai cambiamenti, risultando particolarmente efficace nella risoluzione di problemi complessi nell’ambito dello sviluppo software.

La metodologia Scrum si basa su una serie di principi fondamentali, che includono:

  • la trasparenza, garantendo che tutti nel team siano consapevoli delle sfide;
  • la riflessione, attraverso frequenti incontri per valutare i progressi;
  • e l’adattamento, consentendo ai membri del team di ridefinire le priorità in base ai cambiamenti.

Scrum organizza lo sviluppo software in Sprint, cicli di lavoro di durata fissa (da una a quattro settimane), durante i quali il team sviluppa e rilascia incrementi funzionali del prodotto.
Questi cicli sono rigorosamente limitati nel tempo e non estendibili, anche se il lavoro non è completato.

Gli Sprint sono l’elemento fondamentale della metodologia Scrum, rappresentando il ciclo di lavoro dove le idee si trasformano in valore, inclusi tutti gli altri eventi Scrum, e durano al massimo un mese per garantire iterazioni brevi e feedback regolari.

Questa cadenza permette di ispezionare e adattare il metodo di lavoro e i contenuti del lavoro stesso, mantenendo alta la qualità senza compromettere l’obiettivo dello Sprint.

Durante uno Sprint: non si apportano cambiamenti che possano mettere a rischio l’obiettivo; si affina il Product Backlog e si può ridefinire l’ambito di lavoro in base a nuove informazioni.

Il successo degli Sprint si basa sulla prevedibilità e sull’adattamento degli obiettivi del prodotto e dello Sprint stesso, con il team che si impegna su un obiettivo unico, mantenendo flessibilità sul lavoro specifico da svolgere.

L’empirismo è cruciale, permettendo al team di imparare dall’esperienza in contesti complessi e migliorarsi così continuamente. Le decisioni sono basate su ciò che è già accaduto, e sebbene esistano pratiche di previsione come i burn-downs, burn-ups o i flussi cumulativi, nessuna sostituisce l’importanza dell’empirismo nel percorso di lavoro del team Scrum.

Ma vediamo più in dettaglio come funziona il flusso:

All’inizio di ogni Sprint, nel corso del Sprint Planning, il team sceglie le attività dal Product Backlog da completare, mirando a raggiungere lo Sprint Goal, un obiettivo a breve termine concordato dall’intero team, che definisce il successo dello Sprint.

Importante è la flessibilità di adattare la pianificazione in base a ciò che si apprende, senza compromettere la qualità o deviare dallo Sprint Goal.

Attraverso il Daily Scrum Meeting, il team coordina giornalmente il lavoro, condividendo obiettivi e sfide.

Questa breve riunione quotidiana aiuta a identificare idee, problemi e dipendenze, promuovendo la soluzione di eventuali ostacoli in incontri dedicati.

Alla fine dello Sprint, viene rilasciato un Increment, che deve essere completo e pronto per l’utente finale, basato su una “Definition of Done” chiara. Può esserci più di un Increment per Sprint, permettendo rilasci intermedi.

Lo Sprint termina con lo Sprint Review, dove si ispeziona il lavoro fatto insieme ai stakeholder, e il Retrospective Meeting, un momento di riflessione interna del team per valutare cosa ha funzionato e cosa può essere migliorato.

Queste cerimonie sono essenziali per promuovere la trasparenza, l’ispezione e l’adattamento, principi chiave dell’empirismo su cui si fonda lo Scrum.

Questo approccio è delineato per ottimizzare flessibilità, qualità e collaborazione, assicurando allo stesso tempo che il lavoro svolto sia in linea con gli obiettivi a lungo termine del prodotto.

Nel framework Scrum, l’evento di Sprint Planning è il punto di partenza di ogni Sprint, essenziale per definire il lavoro che verrà svolto.

Durante questa fase, tutto il team Scrum collabora per creare un piano di lavoro basato sulla discussione degli elementi più importanti del Product Backlog e su come questi contribuiscono al raggiungimento dell’obiettivo del prodotto.

Il Product Owner gioca un ruolo cruciale assicurandosi che i partecipanti siano pronti a discutere questi elementi, e a volte si possono invitare anche altri esperti per fornire consulenza.

Il risultato di questo processo, che include lo Sprint Goal, gli elementi del Product Backlog scelti per lo Sprint, e il piano per realizzarli, è noto come Sprint Backlog.

Lo Sprint Planning è limitato ad un massimo di otto ore per gli Sprint di un mese. Per gli Sprint più brevi, la durata di questo evento è solitamente inferiore.

Durante lo Sprint Planning si danno risposte a tre domande chiave:

  • Perché lo Sprint è prezioso?
    Il Product Owner illustra come il prodotto possa aumentare il suo valore nell’attuale Sprint, e insieme al team viene definito un Sprint Goal che comunica l’importanza dello Sprint agli stakeholder.
    Questo obiettivo deve essere stabilito prima della conclusione dello Sprint Planning.
  • Cosa si può fare in questo Sprint?
    I Developer, in dialogo con il Product Owner, selezionano gli elementi dal Product Backlog da includere nello Sprint. Questi possono essere ulteriormente affinati per migliorare la comprensione e la fiducia nel lavoro da svolgere.
    La scelta di quanto lavoro includere si basa sulla conoscenza delle prestazioni passate del team, sulla capacità prevista e sulla loro “Definition of Done“, rendendo così le previsioni per lo Sprint più affidabili.
  • Come verrà eseguito il lavoro?
    Per ogni elemento selezionato del Product Backlog, i Developer pianificano il lavoro necessario per creare un Incremento che rispetti la “Definition of Done“.
    Questo processo può includere la suddivisione degli elementi in lavori più piccoli, della durata massima di un giorno.
    La modalità con cui questo viene fatto spetta esclusivamente ai Developer, senza interferenze esterne su come trasformare gli elementi del Product Backlog in incrementi di valore.

Cos’è uno sprint review e che differenza c’è con lo sprint planning?

Il processo Agile enfatizza due riunioni fondamentali per il successo del progetto: Sprint Planning e Sprint Review.
Entrambe hanno scopi e preparazioni distinti, contribuendo a orientare il team verso l’efficienza e l’efficacia del progetto.

Come spiegato poc’anzi, Sprint Planning è un incontro che si svolge all’inizio di ogni Sprint e di solito dura da due a quattro ore.
Durante la riunione di Sprint Planning, il team pianifica il lavoro per lo Sprint successivo, discutendo compiti e assegnando responsabilità.

L’obiettivo è assicurarsi che tutti sappiano cosa deve essere fatto e quando, mantenendo il team organizzato e focalizzato sugli obiettivi del prodotto.

Prepararsi per questa riunione comporta discutere dei compiti, assegnare responsabilità e allocare il tempo necessario.

La riunione di Sprint Review, invece, si tiene alla fine di ogni Sprint e coinvolge stakeholder, sviluppatori, tester e product owner.

L’obiettivo è valutare il progresso, discutere il raggiungimento degli obiettivi del prodotto e identificare eventuali problemi.
Questo evento mira a garantire trasparenza e offre un momento per feedback, miglioramenti e adeguamenti del Product Backlog.

La preparazione include la raccolta di documenti rilevanti, la creazione di un’agenda, e la pianificazione di dimostrazioni di funzionalità completate.

Le Sprint Review, dunque, valutano il progresso di Sprint correnti, coinvolgendo una vasta gamma di partecipanti per feedback e aggiustamenti.

Al contrario, le Sprint Planning si concentrano sulla pianificazione del lavoro futuro con partecipazione limitata a team di sviluppo e esperti, stabilendo un percorso chiaro per il successo dello Sprint imminente.

Entrambe le riunioni sono in genere guidate dal Product Owner, con la possibilità che entri in gioco anche lo Scrum Master, vale a dire la figura responsabile della rimozione degli ostacoli che limitano la capacità del team di raggiungere l’obiettivo dello Sprint e i deliverable previsti, nel ruolo di facilitatore.
Il facilitatore si assicura che l’agenda sia seguita, che tutti vengano ascoltati e che le discussioni rimangano focalizzate sugli obiettivi.

Suggerimenti per pianificare uno sprint planning efficace

Data la loro strategicità, è importante che queste riunioni siano realmente efficaci.

È importante definire aspettative e obiettivi chiari, stabilire regole di partecipazione e creare un ambiente aperto al dialogo per assicurare che la riunione sia produttiva.

  • Definire aspettative e obiettivi:
    Prima dell’inizio della riunione, è cruciale che tutti i partecipanti siano a conoscenza dei temi che verranno trattati.
    Questo si può ottenere definendo aspettative e obiettivi chiari prima dell’avvio della riunione.
    Facendo in modo che tutti siano sulla stessa lunghezza d’onda riguardo agli obiettivi da raggiungere durante l’incontro, si permette ai partecipanti di concentrarsi su tali tematiche invece di disperdere l’attenzione in conversazioni o compiti non pertinenti. Inoltre, ciò aiuta a mantenere l’organizzazione nel perseguire i risultati desiderati dalla riunione.
  • Stabilire regole di partecipazione:
    Definire le regole di partecipazione prima dell’inizio di una riunione assicura che tutte le voci vengano ascoltate equamente durante le discussioni, senza che nessuno si senta escluso o ignorato.
    Queste regole dovrebbero includere principi come l’assenza di interruzioni mentre qualcuno sta parlando o garantire a ciascuno il tempo di esprimere la propria opinione senza interruzioni da parte degli altri presenti.
    Avere queste regole definite in anticipo garantisce che tutti si sentano a proprio agio nel partecipare alle conversazioni, portando a riunioni più produttive nel complesso.
  • Creare un ambiente aperto alla discussione:
    Creare un ambiente in cui le persone si sentano libere di esprimersi favorisce la collaborazione tra i membri del team, conducendo a decisioni migliori in un contesto di gruppo.
    Consentire l’introduzione di prospettive diverse nelle conversazioni offre inoltre nuove idee che potrebbero aiutare il team a raggiungere l’obiettivo desiderato più velocemente rispetto a situazioni in cui si considera un unico punto di vista nelle discussioni.