Pianificazione dello Sprint: Cos’è e Come Farla?

Che cos'è la Pianificazione dello Sprint?

La pianificazione dello sprint rappresenta la fase iniziale di uno sviluppo agile e fa parte della pianificazione di progetto agile. In questo incontro, tutto il team si riunisce per una riunione di pianificazione dello sprint per definire il lavoro da svolgere nello sprint e creare un piano per raggiungerne gli obiettivi.

Generalmente, la riunione di pianificazione dello sprint è suddivisa in due parti:

1. Il “perché” e il “cosa” dello sprint: il team definisce l'obiettivo dello sprint e concorda cosa verrà sviluppato. Seleziona gli elementi dal product backlog che saranno processati durante lo sprint. Gli strumenti di pianificazione progetto con funzionalità per la pianificazione sprint aiutano a organizzare e prioritizzare gli elementi del backlog, garantendo che il team resti focalizzato e allineato sugli obiettivi.
2. Il “come” dello sprint: gli sviluppatori discutono i dettagli dei singoli elementi del backlog e li suddividono in attività. Ogni attività è pensata per essere completata in un giorno lavorativo o meno e può essere monitorata tramite un software di gestione delle attività.

A seconda della durata dello sprint, la riunione di pianificazione può durare tra le due e le otto ore. Dovrebbe essere timeboxata in base alla lunghezza dello sprint (es. massimo 4 ore di riunione per uno sprint di due settimane).

Al termine dell'incontro dovrebbero essere stati definiti gli obiettivi dello sprint e le attività da completare; da questo momento lo sprint è ufficialmente iniziato.

Perché la Pianificazione dello Sprint è Importante?

La pianificazione dello sprint è importante perché stabilisce una direzione chiara per il prossimo ciclo di lavoro del team. Quando eseguita correttamente, una sessione di pianificazione sprint può:

• Stabilire una comprensione condivisa e chiaramente definita degli obiettivi di progetto
• Consentire al team di prioritizzare e selezionare le attività per il prossimo sprint
• Favorire una migliore allocazione delle risorse e la gestione efficace del tempo
• Favorire collaborazione e comunicazione tra i membri del team

Nel complesso, la pianificazione dello sprint è un passaggio essenziale nella gestione di progetti Agile. Costituisce le basi per uno sprint ben organizzato ed efficiente, permettendo ai team di produrre risultati di alta qualità entro i limiti di tempo stabiliti.

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. Questi membri del team possono includere:

• Il Product Owner: fornisce informazioni sulla visione di prodotto, chiarisce i requisiti e priorizza gli elementi che andranno inclusi nello sprint.
• Lo Scrum Master (in alcuni team chiamato Agile Coach e da non confondere con un project manager): facilita la riunione, si assicura che il flusso di lavoro concordato venga seguito e che i partecipanti sviluppino una comprensione condivisa dell'obiettivo dello sprint. 
• Gli sviluppatori: forniscono competenza tecnica e pareri sulla fattibilità e sullo sforzo necessario per realizzare le user stories.

A volte anche gli stakeholder aziendali partecipano come consulenti se possono offrire prospettive rilevanti o conoscenze utili.

Come Prepararsi alla Riunione di Pianificazione dello Sprint

Per un incontro efficace, il Product Owner (PO) dovrebbe preparare i seguenti elementi:

1. I risultati dell'ultima sprint review e della retrospective dello sprint, così come i feedback degli stakeholder presenti nel backlog.
2. Una panoramica del lavoro già svolto.

Inoltre, il product owner dovrebbe prepararsi alla riunione di pianificazione dello sprint eseguendo diversi processi, che descriverò più dettagliatamente di seguito. Questi includono:

1. Pre-definire l'obiettivo dello sprint con i relativi elementi del backlog prioritizzati che possono essere discussi durante la pianificazione.
2. Raffinare regolarmente il backlog, aggiornando le voci più importanti.
3. Valutare la velocità e la capacità del team per il prossimo sprint.

Descriverò queste tre attività in dettaglio qui sotto.

Lead Smarter in the Age of AI

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Instagram

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Cos'è un Obiettivo di Sprint?

Durante la pianificazione dello sprint, il product owner e gli sviluppatori concordano su un obiettivo specifico dello sprint. L'obiettivo dello sprint descrive il risultato o l'esito del nuovo sprint a cui il team sta lavorando. Si tratta di una pietra miliare a breve termine verso il prodotto finale. 

L'obiettivo è di avere, alla fine dello sprint, un incremento del prodotto pronto che possa già offrire un vantaggio 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 cos'è—una lista di attività o funzionalità da completare. 

Tuttavia, quando si va nei dettagli come la differenza tra un product backlog e uno sprint backlog, le cose si complicano facilmente, quindi preparati e approfondiamo l'argomento!

Product Backlog vs Sprint Backlog

Il team Scrum raccoglie nel product backlog tutte le user story, le epic e i task necessari per creare il prodotto finale. Il product owner poi dà la priorità agli elementi del backlog in modo che le storie con maggior valore per i clienti siano in cima. Questa prioritizzazione viene generalmente fatta insieme agli sviluppatori.

Tuttavia, il product backlog non è una lista definitiva che viene creata all'inizio della fase di sviluppo e poi semplicemente processata. No, questa lista cresce e cambia continuamente nel tempo. 

Cresce sia grazie alle conoscenze acquisite negli sprint che per via di nuovi requisiti che emergono col tempo. Per questo la raffinatura regolare del backlog è necessaria per poter gestire questi cambiamenti.

Ad esempio, supponiamo che il product backlog contenga tutte le storie necessarie per creare un sito web, ad es. homepage, modulo di contatto e pagine prodotto. Se il team marketing si rende improvvisamente conto di aver assolutamente bisogno di una sezione blog sul sito, questa può essere aggiunta al backlog e prioritizzata di conseguenza.

Rispetto al product backlog, lo sprint backlog contiene solo gli elementi selezionati per lo sprint corrente e un obiettivo generale di sprint.

Come Stimare gli Elementi del Backlog

Quanta attività può completare un team durante lo sprint? Questa è una delle domande centrali che gli sviluppatori devono rispondere durante la pianificazione dello sprint. Per poter fare una previsione, vengono fatte delle stime. 

Questo può essere piuttosto impegnativo dato che il team ha a che fare con molte variabili sconosciute. Tuttavia, col tempo e con l'esperienza accumulata dagli sprint completati, il team si perfeziona sempre di più nelle stime.

Come Calcolare la Velocità e la Capacità del Team

Prima di iniziare la stima è fondamentale conoscere la performance media degli sprint precedenti (velocità) e la capacità disponibile del team per il prossimo sprint, che potrebbe diminuire per via di corsi, ferie, ecc. 

Sulla base di queste considerazioni, il team stima la quantità di lavoro (velocità) che può sostenere nello sprint, poi valuta i singoli elementi del backlog e sceglie quanti includerne nello sprint backlog.

Sia, ad esempio, che la velocità media sia stata di 40 story point negli ultimi sprint (ciclo di 2 settimane), e non si prevedono riduzioni significative della disponibilità dei membri del team, allora il team pianificherà mantenendo questa stessa velocità (cioè, gli elementi del backlog selezionati per il prossimo sprint copriranno circa 40 story point).

Sebbene il tempo medio per completare un'attività possa essere solitamente monitorato con un buon strumento di rilevazione dei tempi, puoi anche utilizzare diversi altri metodi di stima per fare capacity planning agile e determinare la velocità del tuo team.

Metodi di Stima: Una Breve Panoramica

Stai cercando di capire meglio l'arte della stima? Con diversi metodi e variabili in gioco, può spesso sembrare un argomento intimidatorio—ma non preoccuparti! Capendo le basi, sarai ben attrezzato per 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 point. 

Gli story point sono un'unità astratta che il team utilizza per stimare lo sforzo richiesto per completare un elemento del backlog. Questo si basa su tre criteri:

1. Quantità di lavoro: Quanti sotto-task devono essere completati per portare a termine la user story?
2. Rischi e incertezze: Tutti i requisiti sono chiari o potrebbero esserci ritardi e cambiamenti imprevisti?
3. Complessità della storia: I singoli sotto-task sono collegati tra loro, al punto che la complessità della storia aumenta? E ci sono dipendenze esterne al team?

La Sequenza di Fibonacci e i Numeri Primi

La pianificazione agile attraverso l'utilizzo della sequenza di Fibonacci e dei numeri primi aiuta i team a fare previsioni che non siano solo frutto di ottimismo intuitivo, ma piuttosto supportate da principi di logica numerica. 

Se una user story ha molte variabili ed è complessa o di vasta portata, assegnarle un numero più alto nella scala di Fibonacci significa che il team è pronto a impegnare abbastanza risorse e sforzi per portarla a termine—perché già conosce la quantità di lavoro insita in tale attività. 

Al contrario, alle storie con meno variabili o risultati più semplici vengono assegnati numeri più bassi, consentendo così una gestione più attenta del tempo e delle energie. In breve, la pianificazione agile toglie sogni e speranze dal tavolo della sala riunioni e vi mette al loro posto numeri concreti e tangibili!

Tuttavia, ricorda che gli story point non sono necessariamente confrontabili tra diversi team di sviluppo software, perché ciascun team valuta l'ampiezza in modo leggermente diverso. Ciò significa che ciò che il team A stima essere una storia da 5 SP potrebbe essere una storia da 8 SP per il team B.

La stima tramite story point è adatta anche a team o progetti più piccoli, poiché con questo metodo il team valuta i compiti in base alla complessità e al tempo necessario per completarli. Altre tecniche includono la stima dello sforzo in base alle 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 a un compito un numero preciso di ore o giorni, puoi assegnargli uno dei quattro tipi di taglia (piccola, media, grande ed extra-large), a seconda della sua complessità o incertezza.

È un modo semplificato, ma sorprendentemente efficace, per assicurarsi che le attività giuste vengano svolte al momento giusto; che tu stia lavorando su progetti di piccola, media o grande scala, tutto quello che devi fare è scegliere la taglia adatta. Assicurati solo che tutti i membri del progetto concordino su come ogni taglia corrisponda a uno specifico livello stimato di sforzo!

Planning Poker

Se stai cercando un modo intelligente per stimare gli elementi del backlog, perché non provare il planning poker? 

È una tecnica popolare che esiste dal 2002, quando James Grenning ha coniato il termine. 

L'approccio è semplice: i membri del team forniscono le loro stime in modo anonimo scegliendo le carte da un mazzo di planning poker, che rappresentano diverse stime (cioè il numero stimato di story point per l'elemento).

Questo incoraggia tutti a esprimere la propria opinione senza timore di giudizio o derisione da parte degli altri. Una volta che tutti i membri hanno inserito le proprie stime e si trova un consenso, il team passa all'elemento successivo.

More Articles

• Gestione dei Progetti per lo Sviluppo Software: Guida 2026

L'Agenda della Pianificazione dello Sprint

Quindi, hai fatto tutte le tue preparazioni necessarie e sei finalmente arrivato al meeting di pianificazione dello sprint. La pianificazione di uno sprint Scrum solitamente segue la seguente agenda:

1. 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.
2. Il PO indica gli elementi (prioritari) dal product backlog che dovrebbero essere implementati per raggiungere l'obiettivo.
3. Il team stima lo sforzo necessario per ciascun elemento, se non è già stato fatto in precedenza (ad es. nella backlog refinement). Se necessario, il team dettaglia o affina singole voci o contenuti (ad es. criteri di accettazione given-then-when).
4. Il team seleziona gli elementi del product backlog che consegnerà entro la fine dello sprint. A questo punto, il product owner discute con gli sviluppatori i compiti da completare, basandosi sul valore per il cliente e lo sforzo richiesto. Gli elementi selezionati sono sufficienti per raggiungere l'obiettivo dello sprint e creare valore per il cliente? Alla fine, gli sviluppatori decidono autonomamente quanto lavoro assumersi nello sprint. Importante: Questa selezione non è un impegno verso il product owner o gli stakeholder, ma una previsione basata sulla stima dello sforzo e sulla velocità media del team.
5. Gli sviluppatori poi si riuniscono per suddividere gli elementi selezionati del backlog in task più piccoli. Idealmente, questi pacchetti di lavoro sono strutturati per essere completati in un giorno o meno.
6. Il backlog dello sprint è composto dall'obiettivo di sprint concordato insieme, dagli elementi del backlog da lavorare e dal piano su come saranno lavorati.
7. Molti team visualizzano il backlog dello sprint e il lavoro da svolgere in una Scrum board. Ogni team ha la propria board e utilizza colonne diverse per documentare i progressi nello sprint. In sostanza, le colonne più importanti di tutte le board dovrebbero essere queste tre: "To Do", "Doing", "Done".

Nella pratica, molti team Scrum suddividono la pianificazione dello sprint in due fasi: 

Nella prima parte si svolgono i primi quattro punti dell'agenda descritti sopra. Il product owner e il team chiariscono le domande: “Perché questo sprint è prezioso?” e “Cosa verrà implementato in questo sprint?”. Gli sviluppatori svolgono la seconda parte senza il PO e si occupano di come realizzare il lavoro selezionato.

Template Agenda Riunione di Sprint Planning

Ti serve un template di agenda per le tue riunioni di pianificazione dello sprint? Scarica il nostro template chiaro e semplice per essere subito operativo nelle tue riunioni di pianificazione dello sprint. Troverai anche una checklist e un modello di email, per maggiore praticità. 

È il momento di "fare ordine" nelle tue riunioni di Sprint Planning

Grazie a questa guida completa, sei ora pronto per trarre il massimo dalle tue sessioni di pianificazione dello sprint. Se hai trovato utile questa guida, ti consigliamo anche di consultare la nostra guida alle riunioni di pianificazione di progetto.

Seguendo i passaggi descritti in questo articolo, i product owner avranno successo nel trasformare il caos in chiarezza e nell'aiutare i membri del team a ottenere il massimo dallo sprint successivo. Scopri di più sul framework Scrum e su altre cerimonie Scrum come il daily Scrum qui.

Per rimanere sempre aggiornato con altri consigli organizzativi e approfondimenti su argomenti legati alla gestione efficace dei progetti guidati dal prodotto, ti invito a iscriverti alla newsletter di The Digital Project Manager. Da lì, continueremo a condividere approfondimenti da esperti del settore e project manager di tutto il mondo.