Pianificazione dello Sprint: Cos’è e Come Farla?
Sei pronto a ottenere il massimo dalla pianificazione dello sprint? Come project manager agile o product owner, spetta a te assicurarti che tutti siano allineati e a ottenere risultati.
È ora di eliminare il caos e soddisfare quei criteri di successo con questa guida definitiva che renderà la tua pianificazione dello sprint così organizzata che potresti persino rivaleggiare con Marie Kondo! Sebbene un buon strumento di gestione dei progetti agile possa essere molto utile, non c’è niente come la mente umana e il lavoro di squadra per creare un piano sprint di successo.
Quindi, in questa guida completa ti accompagnerò in tutto ciò che serve per pianificare sprint di successo—including la definizione dell’obiettivo dello sprint, la preparazione della riunione di pianificazione dello sprint, la strutturazione dell’agenda della riunione e altre best practice.
Sblocca Gratis
Crea un account gratuito per terminare la lettura di questo articolo e unirti a una community di leader innovativi che accedono a strumenti, playbook e approfondimenti per prosperare nell’era dell’AI.
Have an account? Log In
Cos’è la Pianificazione dello Sprint?
La pianificazione dello sprint è la fase iniziale di un ciclo di sviluppo agile e fa parte della pianificazione di progetto agile. Durante questa riunione, l’intero team si riunisce per una riunione di pianificazione dello sprint per definire il lavoro da svolgere nello sprint e creare un piano per raggiungere tali obiettivi.
Generalmente, la riunione di pianificazione dello sprint è solitamente strutturata in due parti:
- Il “perché” e il “cosa” dello sprint: il team stabilisce l’obiettivo dello sprint e concorda cosa verrà fatto. Seleziona gli item del backlog dal product backlog che verranno lavorati nello sprint. Strumenti di pianificazione dei progetti con funzionalità di pianificazione dello sprint possono aiutare a organizzare e a dare priorità agli item del backlog, garantendo che il team rimanga concentrato e allineato sugli obiettivi dello sprint.
- Il “come” dello sprint: gli sviluppatori discutono i dettagli dei singoli item del backlog e li suddividono in task. Ogni attività viene adattata affinché possa essere completata in una giornata lavorativa o meno e può essere tracciata con uno strumento di gestione delle attività.
A seconda della durata dello sprint, la riunione di pianificazione dura tra le due e le otto ore. Deve essere timeboxed in base alla durata dello sprint (es. riunione di massimo 4 ore per uno sprint di due settimane).
Al termine della riunione, l’obiettivo dello sprint e le attività da completare dovrebbero essere stabiliti e lo sprint dovrebbe essere ufficialmente iniziato.
Perché la Pianificazione dello Sprint è Importante?
La pianificazione dello sprint è importante perché stabilisce una direzione chiara per lo sprint imminente di un team. Se ben condotta, una sessione di pianificazione dello sprint può:
- Stabilire una comprensione condivisa e chiara degli obiettivi e dei risultati del progetto
- Consentire ai team di dare priorità e selezionare le attività per lo sprint in arrivo
- Favorire un'efficace allocazione delle risorse e gestione del tempo
- Favorire la collaborazione e la comunicazione tra i membri del team
Nel complesso, la pianificazione dello sprint è un passaggio preparatorio fondamentale nella gestione agile dei progetti. Getta le basi per uno sprint ben organizzato ed efficiente, permettendo ai team di fornire risultati di alta qualità entro i limiti di tempo definiti.
Chi Partecipa alla Pianificazione dello Sprint?
In breve, l’intero team Scrum dovrebbe essere coinvolto nella pianificazione dello sprint e partecipare all’evento Scrum all’inizio di ogni sprint. I membri del team possono includere:
- Il product owner: Fornisce indicazioni sulla vision del prodotto, chiarisce i requisiti e dà priorità agli item del backlog da includere nello sprint.
- Lo Scrum master (chiamato agile coach in alcuni team e da non confondere con il project manager): Facilita la riunione, si assicura che il flusso di lavoro concordato venga seguito e che i partecipanti sviluppino una comprensione comune dell’obiettivo dello sprint.
- Gli sviluppatori: Forniscono competenze tecniche e indicazioni sulla fattibilità e lo sforzo necessario per implementare le user story.
A volte anche stakeholder dell’azienda partecipano come consulenti se possono offrire una prospettiva importante o conoscenze utili.
Come Prepararsi alla Riunione di Pianificazione dello Sprint
Per una riunione efficace, il product owner (PO) dovrebbe preparare quanto segue:
- I risultati dell’ultima revisione dello sprint e della retrospettiva dello sprint, così come i feedback degli stakeholder presenti nel backlog.
- Una panoramica del lavoro già svolto.
Inoltre, il product owner dovrebbe prepararsi per una riunione di pianificazione dello sprint svolgendo diversi processi, che spiegherò più in dettaglio di seguito. Questi includono:
- Predefinire l’obiettivo dello sprint con i relativi elementi prioritari del backlog che potranno essere discussi nella pianificazione.
- Raffinare regolarmente il backlog, in cui vengono aggiornate le voci più importanti.
- Valutare la velocità e la capacità del team per il prossimo sprint.
Descriverò queste tre attività in dettaglio qui sotto.
Cos’è un obiettivo di sprint?
Durante la pianificazione dello sprint, il product owner e gli sviluppatori stabiliscono insieme un obiettivo specifico per lo sprint. L’obiettivo di sprint descrive il risultato o l’output del nuovo sprint su cui il team sta lavorando. Si tratta di una tappa a breve termine verso la realizzazione del prodotto finale.
L’obiettivo è che, al termine dello sprint, ci sia un incremento del prodotto consegnabile che offra già un beneficio ai clienti.
Cos’è un Backlog?
Se sei un product owner, probabilmente hai sentito il termine "backlog" più volte di quante ne puoi contare. Ma che cos’è esattamente? Certo, a un livello fondamentale, sappiamo tutti di cosa si tratta: un elenco di attività o funzionalità da completare.
Tuttavia, quando si entra nei dettagli pratici, ad esempio la differenza tra un product backlog e uno sprint backlog, le cose si complicano rapidamente, quindi preparati e approfondiamo!
Backlog di prodotto vs Backlog dello sprint
Il team Scrum raccoglie tutte le user story, le epic e le attività necessarie per creare il prodotto finale nel product backlog. Il product owner dà priorità agli elementi del backlog in modo che le story di maggior valore per i clienti siano in cima. Questa prioritizzazione viene solitamente fatta insieme agli sviluppatori.
Tuttavia, il product backlog non è un elenco definitivo creato all’inizio della fase di sviluppo e poi semplicemente eseguito. No, questa lista cresce e cambia costantemente nel tempo.
Cresce grazie sia alle conoscenze acquisite negli sprint, sia a nuovi requisiti che emergono in futuro. Pertanto, è necessario un affinamento regolare del backlog per gestire questi cambiamenti.
Ad esempio, supponiamo che il product backlog includa tutte le story necessarie per costruire un sito web, ad esempio homepage, modulo di contatto e pagine prodotto. Se il team marketing improvvisamente si rende conto di aver assolutamente bisogno di una sezione blog sul sito, questa può essere inserita nel backlog e priorizzata di conseguenza.
Rispetto al product backlog, il backlog dello sprint contiene solo gli elementi selezionati per lo sprint corrente e un obiettivo generale di sprint.
Come Stimare gli Elementi nel Backlog
Quante attività può completare un team nello sprint? Questa è una delle questioni centrali a cui gli sviluppatori devono rispondere durante la pianificazione dello sprint. Per riuscire a fare una previsione, viene effettuata una stima.
Questo può essere piuttosto impegnativo perché il team si trova a gestire molte variabili sconosciute. Tuttavia, con il tempo e con l’esperienza maturata grazie agli sprint già conclusi, la capacità di stima del team migliora sempre di più.
Come Calcolare la Velocità e la Capacità del Team
Prima di iniziare la stima, è fondamentale conoscere la media delle performance degli sprint precedenti (velocità) e la capacità disponibile del team per lo sprint in arrivo, che potrebbe essere ridotta a causa di corsi, ferie, ecc.
Sulla base di queste valutazioni, il team stima il volume di lavoro (velocità) che può gestire nello sprint, valuta i singoli elementi del backlog e sceglie quanti includerne nello sprint backlog.
Supponiamo che la velocità media sia stata di 40 story point negli ultimi sprint (ogni ciclo dura 2 settimane) e che non sia prevista una significativa riduzione della disponibilità dei membri del team; in questo caso, il team pianificherà mantenendo la stessa velocità (ovvero gli item selezionati per il prossimo sprint copriranno circa 40 story point).
Sebbene il tempo medio per completare un'attività possa solitamente essere tracciato con un buon strumento di rilevazione dei tempi, puoi anche utilizzare diversi altri metodi di stima per fare la pianificazione della capacità agile e determinare la velocità del tuo team.
Metodi di stima: una breve panoramica
Vuoi comprendere meglio l'arte della stima? Con diversi metodi e variabili in gioco, spesso può sembrare un argomento intimidatorio—ma non preoccuparti! Capendo le basi, sarai presto pronto a stimare il tuo backlog in pochissimo tempo.
Story Points
Molti team agili che lavorano su progetti a lungo termine stimano la loro velocità in story points.
Gli story points sono un'unità astratta che il team utilizza per stimare lo sforzo necessario per completare un elemento del backlog. Questo si basa su tre criteri:
- Quantità di lavoro: Quanti sotto-task devono essere completati per terminare la user story?
- Rischi e incertezza: Tutti i requisiti sono chiari o potrebbero esserci ritardi e cambiamenti imprevisti?
- Complessità della storia: I singoli sotto-task sono collegati tra loro, facendo sì che la complessità della storia aumenti? E ci sono dipendenze esterne al team?
La sequenza di Fibonacci & I numeri primi
La pianificazione agile con l'utilizzo della sequenza di Fibonacci e dei numeri primi aiuta i team a fare previsioni che non si basano solo sull'ottimismo, ma sono invece supportate da principi di logica numerica.
Se una user story ha molte variabili ed è complessa o di ampia portata, allora assegnarle un numero più alto sulla scala di Fibonacci significa che il team è preparato a impegnare abbastanza risorse e sforzi per portarla a termine—perché conoscono già la quantità di lavoro insita in tale compito.
Al contrario, le storie con meno variabili o risultati più semplici ottengono numeri più bassi—permettendo così una migliore pianificazione di tempi ed energie. In breve, la pianificazione agile toglie sogni e speranze dal tavolo delle riunioni e mette al loro posto numeri concreti e tangibili!
Tuttavia, tieni presente che gli story points non sono necessariamente comparabili tra diversi team di sviluppo software, poiché ciascun team stima il lavoro in modo leggermente diverso. Ciò significa che ciò che il team A valuta come una storia da 5 SP potrebbe essere una storia da 8 SP per il team B.
La stima tramite story points è adatta anche per team o progetti più piccoli, poiché con questo metodo il team valuta i compiti in base alla complessità e al tempo necessario per elaborarli. Altre tecniche includono la stima basata sulle taglie delle magliette o il metodo del planning poker.
Taglie delle magliette
Stimare gli elementi del backlog con le taglie delle magliette è un approccio interessante per aiutare a dare priorità alle attività di progetto. Invece di assegnare un numero esatto di ore o giorni a un'attività, puoi assegnarle uno dei quattro tipi di taglia (piccola, media, grande ed extra-large) in base al suo grado di complessità o incertezza.
È un modo semplificato ma sorprendentemente efficace per assicurarsi che le attività giuste vengano svolte al momento giusto—sia che tu stia gestendo progetti piccoli, medi o di grande scala, tutto ciò che devi fare è scegliere la taglia più appropriata. Basta assicurarsi che tutti i soggetti coinvolti nel progetto siano d'accordo su come ogni taglia corrisponda a uno specifico livello stimato di sforzo!
Planning Poker
Se cerchi un modo fantasioso per stimare gli elementi del tuo backlog, perché non provare il planning poker?
È una tecnica molto diffusa che esiste dal 2002, quando James Grenning coniò il termine.
L'approccio è semplice: i membri del team forniscono le loro stime in forma anonima scegliendo delle carte da un mazzo di planning poker che rappresentano stime diverse (cioè il numero stimato di story points per quell'elemento).
Questo incoraggia tutti ad esprimere la propria opinione senza timore di essere giudicati o derisi dagli altri. Una volta che tutti i membri hanno inserito la loro stima e si raggiunge un consenso, il team passa all'elemento successivo.
L'agenda della pianificazione dello sprint
Dunque, hai fatto tutte le preparazioni necessarie ed è finalmente arrivato il momento della riunione di sprint planning. La pianificazione di uno sprint Scrum segue solitamente la seguente agenda:
- Il product owner (PO) presenta il suo obiettivo di sprint predefinito e condivide la sua idea su come aumentare il valore del prodotto nello sprint successivo. L'obiettivo finale dello sprint viene definito congiuntamente dal product owner e dagli sviluppatori.
- Il PO indica le voci (prioritarie) dal product backlog che dovrebbero essere implementate per raggiungere l'obiettivo.
- Il team stima l'impegno necessario per le singole voci, se ciò non è già stato fatto in precedenza (ad es. durante la refinement del backlog). Se necessario, il team affina alcune voci o contenuti (ad es. criteri di accettazione Given-When-Then).
- Il team seleziona le voci del product backlog che consegnerà entro la fine dello sprint. A questo punto, il product owner discute i compiti da svolgere con gli sviluppatori in base al valore per il cliente e all’impegno richiesto. Le voci selezionate sono sufficienti per soddisfare l'obiettivo dello sprint e creare valore per il cliente? Alla fine, sono gli sviluppatori a decidere autonomamente quanto lavoro prendersi in carico nello sprint. Importante: Questa selezione non rappresenta un impegno verso il product owner e gli stakeholder, ma una previsione basata sulla stima dell’impegno e sulla velocità media del team.
- Gli sviluppatori poi si riuniscono per suddividere le voci selezionate del backlog in compiti più piccoli. Idealmente, questi pacchetti di lavoro sono pensati per essere completati in un giorno o meno.
- Lo sprint backlog è costituito dall'obiettivo di sprint concordato, dalle voci del backlog da processare e dal piano su come verranno affrontate.
- Molti team visualizzano lo sprint backlog e il lavoro da svolgere su una Scrum board. Ogni team ha la propria board e utilizza diverse colonne per documentare i progressi nello sprint. In sostanza, le colonne fondamentali di ogni board dovrebbero essere le seguenti tre: "Da fare", "In corso", "Fatto".
Nella pratica, molti team Scrum suddividono la pianificazione dello sprint in due fasi:
Nella prima parte, si svolgono i primi quattro punti dell'ordine del giorno descritto sopra. Il product owner e il team chiariscono le domande: “Perché questo sprint ha valore?” e “Cosa verrà implementato in questo sprint?” Gli sviluppatori gestiscono la seconda parte senza il PO e si occupano di come svolgere il lavoro selezionato.
Template Agenda Riunione Sprint Planning
Hai bisogno di un modello di agenda per le tue riunioni di sprint planning? Scarica il nostro modello chiaro e immediato per iniziare subito con le tue riunioni di pianificazione sprint. Troverai anche una checklist e un modello email, per maggiore comodità.
È Ora di Fare Ordine nelle Tue Riunioni di Sprint Planning
Con questa guida completa, sei ora pronto a sfruttare al meglio le tue sessioni di pianificazione sprint. Se hai trovato utile questa guida, ti consigliamo anche di dare un’occhiata alla nostra guida sulle riunioni di pianificazione progetto.
Seguendo i passaggi illustrati in questo post, i product owner avranno sicuramente successo nel trasformare il caos in chiarezza e aiutare i membri del team a centrare il prossimo sprint. Scopri di più sul framework Scrum e altre cerimonie Scrum, come il daily Scrum, qui.
Per restare aggiornato con altri consigli organizzativi e approfondimenti su argomenti legati alla gestione efficace di progetti product-driven, ti invito a iscriverti alla newsletter di The Digital Project Manager. Da lì, continueremo a portare insight da esperti del settore e project manager da tutto il mondo.
