C’è un motivo per cui le previsioni meteorologiche indicano una probabilità di pioggia del 70% invece di promettere che pioverà esattamente alle 15:00. Utilizzano le informazioni disponibili, tengono conto dell’incertezza e si aggiornano man mano che arrivano nuovi dati. Puoi comunque pianificare il tuo pomeriggio in base a queste previsioni, purché non scambi la previsione per una garanzia.
La pianificazione dello sprint funziona secondo un principio simile. Un team Scrum dispone di un product backlog, di una stima della propria capacità disponibile e di un obiettivo che desidera raggiungere. Tuttavia, alcuni dettagli del lavoro diventano chiari solo man mano che lo sprint procede. Pianificare ogni ora in anticipo lascia poco spazio a tali scoperte, mentre procedere senza una direzione condivisa rende più difficile decidere a cosa prestare attenzione.
L'obiettivo è concordare un risultato di valore e effettuare una previsione della quantità di lavoro che il team è in grado di completare per raggiungerlo. Partendo da lì, il team può adattare il proprio piano man mano che acquisisce ulteriori informazioni, senza perdere di vista l'obiettivo dello sprint.
Questa guida tratta la preparazione del backlog, un programma con tempistiche precise, calcoli pratici della capacità e un esempio concreto che mostra come adeguare il piano durante lo sprint.
TL;DR La pianificazione dello sprint riunisce il team Scrum per concordare un unico obiettivo dello sprint, selezionare gli elementi del backlog e stabilire un piano di consegna iniziale:
- Preparati perfezionando il lavoro imminente e verificando la disponibilità, gli elementi non completati, le dipendenze e la Definizione di Terminato
- Basa la previsione sulla capacità effettiva e sulle prestazioni passate, tenendo conto di ferie, riunioni, attività di supporto e incertezze, senza conteggiare due volte gli impegni
- Concludi la pianificazione con uno sprint backlog condiviso, quindi adatta il piano di consegna man mano che il team acquisisce ulteriori informazioni, senza compromettere l’obiettivo dello sprint
- Utilizza il programma di esempio di due ore e l’esempio pratico di calcolo della capacità come punti di partenza, adattandoli alle esigenze del team
Che cos’è la pianificazione dello sprint?
La pianificazione dello sprint è un evento Scrum che si tiene all’inizio di ogni sprint per concordare ciò che il team intende realizzare e come affronterà il lavoro. Riunisce l’intero team Scrum, inclusi il Product Owner, lo Scrum Master e gli sviluppatori. Possono partecipare anche altri specialisti, come gli ingegneri della sicurezza o i responsabili delle relazioni con i clienti, quando il loro contributo aiuta il team a prendere decisioni informate.
Secondo la Guida allo Scrum, ogni sessione di pianificazione dovrebbe produrre tre elementi: un obiettivo dello sprint che spieghi il valore del lavoro, una selezione di elementi del product backlog che supportino tale obiettivo e un piano iniziale per la loro consegna. Insieme, questi elementi formano lo sprint backlog, che gli sviluppatori continuano ad aggiornare man mano che lo sprint procede.
La Guida allo Scrum prevede un massimo di otto ore per uno sprint di un mese, mentre gli sprint più brevi richiedono solitamente meno tempo. Con un backlog ben definito, il programma riportato di seguito si conclude in due ore.
Se alcuni di questi termini ti sono poco familiari, il nostro glossario illustra le nozioni di base relative all’Agile e a Scrum.
Le tre domande a cui risponde la pianificazione dello sprint
Ogni sessione di pianificazione dello sprint ruota attorno a tre domande:
- Perché questo sprint è importante?
- Cosa possiamo realizzare?
- E come porteremo a termine il lavoro?
La Guida allo Scrum organizza la pianificazione attorno a queste domande, partendo dal valore che si desidera fornire. Una volta che tutti hanno ben chiaro questo punto, è più facile decidere quali elementi del backlog meritano attenzione e quanto lavoro il tuo team possa ragionevolmente assumersi.
| Domanda | Chi conduce la riunione | Risultato | Esempio per uno sprint di 2 settimane |
|---|---|---|---|
| Perché questo sprint è importante? | Il Product Owner propone; l’intero team concorda | Obiettivo dello sprint | I nuovi clienti possono pagare con scheda di credito al momento del checkout senza dover contattare il reparto commerciale |
| Cosa si può realizzare in questo sprint? | Gli sviluppatori effettuano la selezione, insieme al titolare del prodotto | Elementi selezionati del backlog | Modulo di pagamento con scheda, integrazione con il provider di servizi di pagamento, email di ricevuta, gestione degli errori |
| Come verrà terminato il lavoro scelto? | Sviluppatori | Piano iniziale delle attività | Gli elementi vengono suddivisi in attività, spesso della durata di un giorno o meno ciascuna, con le responsabilità iniziali concordate |
Perché lo sprint è importante
L’obiettivo dello sprint fornisce al team una direzione verso cui lavorare e aiuta gli stakeholder a comprendere cosa aspettarsi. Concordate questo obiettivo con il vostro team Scrum prima che la sessione di pianificazione giunga al termine.
Descrivi un risultato riconoscibile, come ad esempio “Gli utenti in versione di prova possono invitare i colleghi”, piuttosto che un traguardo di carico di lavoro del tipo “Completare 34 story point”. Se dovesse presentarsi un problema imprevisto, l’obiettivo aiuta il team a decidere quali attività modificare, preservando al contempo il risultato previsto.
Per saperne di più: Come scrivere obiettivi di sprint efficaci (+esempi)
Cosa può portare a termine il team in questo sprint
Una volta concordato l’obiettivo, è il momento di stabilire cosa il team possa realisticamente realizzare.
Gli sviluppatori selezionano gli elementi del backlog in accordo con il Product Owner, tenendo conto della capacità disponibile, delle prestazioni passate e della Definizione di Completamento. Questo è anche il momento giusto per rivedere eventuali impegni esistenti che potrebbero influire sul tempo a disposizione del team per il lavoro dello sprint.
Molti team utilizzano gli story point per confrontare il lavoro richiesto e la complessità relativi degli elementi del backlog. Una scala di Fibonacci può aiutare a strutturare tali discussioni, in particolare quando il lavoro richiesto non è chiaro.
Se non hai familiarità con gli story point o vuoi vedere come vengono utilizzati nella pratica, ecco una guida dettagliata al processo di stima.
Come il team svolgerà il lavoro
Una volta effettuata la selezione degli elementi del backlog, gli sviluppatori definiscono come trasformarli in un incremento di prodotto finito che soddisfi la Definizione di Terminato. La Guida allo Scrum suggerisce di suddividere gli elementi più grandi in parti di lavoro più piccole, spesso della dimensione di un giorno o meno.
Ciò non significa che sia necessario mappare ogni singola ora dello sprint. I primi giorni potrebbero richiedere un piano più dettagliato, mentre le attività successive possono rimanere aperte ad adeguamenti man mano che emergono nuovi dettagli. Considerare le stime iniziali come impegni definitivi può mettere sotto pressione il team affinché rispetti i numeri originali, anche se l’ambito del lavoro dovesse cambiare a metà percorso.
Come spiega Dave West, CEO di Scrum.org:
Una previsione utilizzata per difendere una scadenza favorisce proprio quei comportamenti che minano la fiducia, come gonfiare le stime, nascondere i rischi o ridefinire silenziosamente il concetto di “terminato” per raggiungere un numero.
Una previsione utilizzata per difendere una scadenza favorisce proprio quei comportamenti che minano la fiducia, come gonfiare le stime, nascondere i rischi o ridefinire silenziosamente il concetto di “terminato” per raggiungere un numero.
Qual è la differenza tra la pianificazione dello sprint e l’affinamento del backlog?
L'affinamento del backlog offre al tuo team una comprensione più chiara del lavoro imminente prima che sia il momento di decidere cosa includere nel prossimo sprint. La pianificazione dello sprint si basa su tale preparazione per concordare un obiettivo, selezionare gli elementi del backlog e stabilire un piano di consegna iniziale.
Le due attività hanno finalità diverse all’interno di Scrum:
| Dimensione | Affinamento del backlog | Pianificazione dello sprint |
|---|---|---|
| Scopo | Chiarire, suddividere e stimare i prossimi elementi del backlog | Definisci l’obiettivo dello sprint, seleziona il lavoro e pianifica la consegna |
| Tempistiche | In corso per tutta la durata dello sprint | All'inizio di ogni sprint |
| Stato dello Scrum | Un’attività continua | Un evento Scrum formale con un limite di tempo |
| Chi partecipa | Product Owner e sviluppatori coinvolti | L'intero team Scrum |
| Risultato | Elementi del backlog con dettagli, stime e ambito più chiari | Lo sprint backlog: l’obiettivo dello sprint, gli elementi selezionati e il piano di consegna |
Assicurati che un numero sufficiente di elementi del backlog imminenti sia sufficientemente definito, in modo che il team abbia scelte chiare durante la pianificazione dello sprint. Il livello di preparazione necessario dipende dalla rapidità con cui cambiano le priorità e dal grado di incertezza residua. Gli elementi più in fondo al backlog possono rimanere meno dettagliati fino a quando non si avvicinano alla fase di selezione.
Leggi anche: Per ulteriori indicazioni, consulta i nostri articoli sulla gestione del backlog e su come mantenere il backlog di prodotto organizzato e ordinato per priorità.
Come prepararsi alla pianificazione dello sprint
Qualche giorno prima, verifica che il backlog abbia una forma corretta e che tutti dispongano delle informazioni necessarie per prendere decisioni. In questo modo, potrai dedicare la sessione a discutere cosa consegnare e come affrontarlo, senza dover risolvere ogni requisito partendo da zero.
Ecco una lista di controllo da seguire prima del tuo prossimo sprint:
- Formulare un obiettivo dello sprint: Chiedi al Product Owner di proporre un risultato che supporti l’obiettivo di prodotto più ampio, fornendo al team spunti concreti di discussione
- Esamina il product backlog: assicurati che gli elementi con la massima priorità siano ordinati, compresi e, ove necessario, stimate
- Verifica la disponibilità del team: chiedi agli sviluppatori di condividere le ferie programmate, i turni di assistenza e altri impegni che potrebbero influire sulla loro capacità
- Riesamina il lavoro incompiuto: esamina le attività riportate dallo sprint precedente e gli eventuali miglioramenti individuati durante la retrospettiva
- Identifica le dipendenze: contrassegna il lavoro che richiede il contributo o l’approvazione di un altro team e chiarisci chi si occuperà del coordinamento
- Rivedi la definizione di "terminato": assicurati che tutti comprendano gli standard di qualità che ogni elemento del backlog completato deve soddisfare
Se pianifichi la retrospettiva dello sprint e la sessione di pianificazione a breve distanza l’una dall’altra, lascia tempo sufficiente per una discussione approfondita in entrambe. I risultati della retrospettiva dovrebbero influenzare il piano dello sprint successivo, quindi assicurati che nessuna delle due riunioni risulti affrettata.
Programma della pianificazione dello sprint: un esempio con tempistiche per uno sprint di 2 settimane
Per uno sprint di due settimane, inizia con una sessione di pianificazione di due ore, soprattutto se il backlog è già stato perfezionato. Prevedi del tempo aggiuntivo se il lavoro comporta dipendenze complesse o diverse decisioni che richiedono una discussione.
Puoi adattare questo modello di programma alle esigenze del tuo team.
| Tempo | Elemento del programma | Chi conduce la riunione | Risultato atteso |
|---|---|---|---|
| 0:00–0:10 | Esamina i risultati dello sprint precedente, il lavoro non completato e le azioni da intraprendere in base alla retrospettiva | Lo Scrum Master funge da facilitatore | Comprensione di condivisione di ciò che richiede attenzione |
| 0:10–0:30 | Discutete l’obiettivo dello sprint proposto dal Product Owner e concordate il risultato desiderato | L'intero team Scrum | Una bozza di obiettivo dello sprint comprensibile a tutti |
| 0:30–0:45 | Verifica la disponibilità del team ed esamina eventuali limiti di capacità | Sviluppatori | Un quadro realistico della capacità disponibile |
| 0:45–1:15 | Seleziona gli elementi del backlog che supportano l’obiettivo | Sviluppatori, insieme al titolare del prodotto | Una selezione del lavoro che il team ritiene di poter completare |
| 1:15–1:45 | Suddividi gli elementi selezionati e discuti l’approccio alla consegna | Sviluppatori | Un piano iniziale per completare il lavoro |
| 1:45–2:00 | Esamina le dipendenze, verifica il livello di fiducia e definisci l’obiettivo dello sprint | L'intero team Scrum | Un obiettivo dello sprint concordato e uno sprint backlog pronto per essere utilizzato dal team |
Prima di concludere, puoi ricorrere a un rapido controllo del livello di fiducia, come il Fist of Five, in cui tutti effettuano una valutazione della propria fiducia nel piano da zero a cinque dita. Se qualcuno assegna un punteggio basso, chiedi quale sia la causa della preoccupazione. Potrebbe rivelare una dipendenza irrisolta, una previsione eccessivamente ambiziosa o un requisito che necessita di ulteriore discussione.
L'obiettivo è quello di far emergere eventuali preoccupazioni finché c'è ancora tempo per adeguare il piano.
Come condurre la pianificazione dello sprint in 6 passaggi
Una volta preparato il backlog e confermati i partecipanti, avvia la sessione di pianificazione. L’obiettivo è aiutare il team a trasformare le proprie priorità e la capacità disponibile in un piano che sia in grado di realizzare con sicurezza.
Fase 1: Esaminare il lavoro precedente e concordare un obiettivo dello sprint
Inizia con una breve panoramica di ciò che è stato completato, di ciò che rimane incompiuto e di eventuali azioni emerse dalla retrospettiva che potrebbero influenzare il prossimo sprint. Concentrati su tutto ciò che potrebbe modificare le priorità o l’approccio del team, piuttosto che riesaminare l’intera revisione dello sprint.
Chiedi quindi al Product Owner di presentare l’obiettivo dello sprint proposto e di spiegare in che modo esso contribuisca al raggiungimento dell’obiettivo di prodotto più ampio. Concedi agli sviluppatori lo spazio necessario per mettere in discussione l’ambito dell’obiettivo, segnalare eventuali dipendenze e suggerire modifiche.
Ad esempio, se l’obiettivo è consentire ai clienti di completare il checkout senza contattare il reparto commerciale, concordate quale debba essere l’esito positivo di un checkout riuscito. Include la conferma del pagamento e la gestione degli errori? L’invio automatico della ricevuta è essenziale per la prima versione?
Queste discussioni ti aiutano a definire un risultato verso cui il team possa lavorare. La formulazione può evolversi man mano che vengono selezionati gli elementi del backlog, ma tutti dovrebbero concordare sull’obiettivo finale prima che la pianificazione giunga al termine.
Passaggio 2: Calcola la capacità disponibile del team
Prima della selezione del lavoro, stabilisci quanto tempo i tuoi sviluppatori possano realisticamente dedicare allo sprint.
Inizia dal numero di giorni lavorativi e dalla disponibilità prevista di ciascuna persona. Poi tieni conto delle ferie programmate, degli eventi Scrum, delle responsabilità di supporto e di altri impegni noti. Se uno sviluppatore dedica metà della settimana alla gestione di problemi di produzione, quelle ore sono già impegnate e non sono disponibili per il lavoro previsto nello sprint.
Un semplice calcolo è: Capacità disponibile = Ore lavorative totali − Impegni noti
Ad esempio, uno sviluppatore con 80 ore lavorative in due settimane potrebbe avere 8 ore di ferie, 10 ore di riunioni e 12 ore di supporto. Ciò lascia 50 ore prima di tenere conto di eventuali ulteriori incertezze.
Confronta questo dato con le prestazioni passate del team. La velocità (velocity) indica la quantità di lavoro completata dal team negli sprint precedenti, mentre la capacità riflette il tempo a disposizione per questo sprint.
Consiglio da esperto: se utilizzi le ore per la pianificazione della capacità, mantienile separate dagli story point. Si tratta di due misure diverse e non esiste una conversione universale tra di esse.
Passaggio 3: Rivalutare il lavoro non completato dello sprint precedente
Gli elementi del backlog non completati meritano un'altra valutazione prima di aggiungerli al nuovo sprint. Un elemento che era importante due settimane fa potrebbe aver cambiato priorità, oppure il team potrebbe aver appreso qualcosa che influisce sulla quantità di lavoro rimanente.
Esamina ogni elemento con il titolare del prodotto e valuta:
- Rilevanza: È ancora in linea con l’obiettivo dello sprint proposto o con un’altra priorità importante del prodotto?
- Lavoro residuo: Quanto lavoro resta da fare ora che una parte dell’elemento è stata completata?
- Dipendenze: C'è qualcosa che impedisce al team di fare progressi?
- Priorità: Questo elemento dovrebbe avere la priorità sugli elementi del backlog recentemente perfezionati?
Per il lavoro che rientra ancora nello sprint, usa lo sforzo residuo per valutare quanta capacità sarà necessaria. Un elemento completato solo a metà potrebbe richiedere meno lavoro rispetto alla stima originale, ma continua a essere considerato incompiuto finché non soddisfa la Definizione di Terminato.
Passaggio 4: Seleziona gli elementi del backlog che supportano l’obiettivo
Una volta chiarite la capacità e il lavoro in sospeso, gli sviluppatori possono selezionare gli elementi del product backlog che ritengono di poter completare.
Inizia con gli elementi che forniscono diretto supporto all’obiettivo dello sprint. Discuti i relativi criteri di accettazione, le dipendenze tecniche e qualsiasi incertezza che potrebbe influire sulla consegna. Se un elemento è troppo ampio o poco chiaro, valuta la possibilità di suddividerlo in parti più piccole in grado di fornire valore all’interno dello sprint.
Potresti anche avere spazio per la manutenzione o altre priorità relative al prodotto, ma verifica se intraprendere quel lavoro potrebbe mettere a rischio l’obiettivo principale.
Quanta capacità dovresti riservare?
Pianificare solo l’80% della capacità disponibile può essere un punto di partenza ragionevole per i team che devono gestire regolarmente attività di supporto impreviste, ma Scrum non prescrive una percentuale fissa.
Se il tuo team ha subito frequenti interruzioni, potresti riservare il 10–20% della sua capacità adeguata e confrontare tale margine con quanto è stato necessario durante gli sprint precedenti. Un team con un carico di lavoro stabile e poche interruzioni potrebbe aver bisogno di meno. Uno che gestisce un servizio attivo con frequenti incidenti potrebbe aver bisogno di più.
Evita di conteggiare due volte lo stesso impegno. Se le ore di assistenza programmate sono già state detratte nella Fase 2, il margine aggiuntivo dovrebbe coprire l’incertezza al di là di quel carico di lavoro noto. Utilizza la capacità risultante come linea guida per la discussione, non come traguardo da raggiungere.
Ricorda: uno sprint con capacità inutilizzata non è necessariamente sottodimensionato. Se hai selezionato un carico di lavoro sufficiente per raggiungere l’obiettivo dello sprint, riempire le ore rimanenti con attività non correlate può creare priorità contrastanti. A volte una previsione più modesta è più realistica, specialmente quando il lavoro selezionato comporta una significativa incertezza.
Passaggio 5: Suddividi il lavoro e verifica le dipendenze
Una volta effettuata la selezione degli elementi del backlog, gli sviluppatori possono definire come realizzarli. Ciò può comportare la suddivisione degli elementi più grandi in attività di sviluppo, test, integrazione e revisione.
Esamina attentamente l’ordine delle attività. Se l’interfaccia di checkout dipende dall’integrazione con un provider di servizi di pagamento, il team deve capire entro quando tale integrazione dovrà essere pronta. Se un altro team deve approvare una modifica alla sicurezza, chiarisci come e quando verrà presa tale decisione.
Pianifica il lavoro immediato in modo più dettagliato, lasciando aperte le attività successive per ulteriori discussioni. La Guida allo Scrum suggerisce di suddividere le attività di selezione in elementi più piccoli, in genere con una dimensione massima di un giorno o meno, ma sono gli sviluppatori a decidere come organizzare e distribuire il lavoro.
Verifica che il piano tenga conto della Definizione di Completamento, compresi i test essenziali e le attività di integrazione. Se una dipendenza dovesse impedire la consegna, riesamina gli elementi selezionati o modifica l’approccio di consegna prima di finalizzare il piano.
Passaggio 6: Definire e effettuare la condivisione dello sprint backlog
Registra l’obiettivo dello sprint, gli elementi selezionati del product backlog e il piano di consegna iniziale in un luogo accessibile al team e aggiornabile. Insieme, questi elementi dovrebbero chiarire ciò che il team intende raggiungere e a quali attività prestare attenzione in seguito.
Prima di chiudere la riunione, assicurati che l’obiettivo sia stato concordato e dai a tutti la possibilità di sollevare eventuali dubbi rimanenti sulle previsioni. Se una dipendenza importante o un problema di capacità non è stato risolto, discuti cosa deve cambiare prima che il team inizi a lavorare.
Durante lo sprint, il Daily Scrum offre agli sviluppatori l’opportunità di verificare lo stato dei progressi compiuti verso l’obiettivo e di adeguare lo sprint backlog. Un grafico burndown o burnup può aiutare a mostrare l’andamento dei progressi, mentre le attività sottostanti forniscono i dettagli. Se nuove informazioni influenzano l’ambito selezionato, gli sviluppatori possono discutere gli adeguamenti con il Product Owner senza mettere a rischio l’obiettivo dello sprint.
Esempio di pianificazione dello sprint: un team composto da 6 sviluppatori
Vediamo come queste decisioni si applicano nella pratica.
Immagina di dover pianificare uno sprint di due settimane per un prodotto di fatturazione B2B. Il tuo team è composto da sei sviluppatori e l’obiettivo proposto per lo sprint è: “I nuovi clienti possono pagare con carta di credito al momento del checkout senza dover contattare il reparto commerciale.”
Prima di effettuare la selezione degli elementi del backlog, è necessario sapere di quanto tempo dispone il team. Per questo esempio, supponiamo che ogni sviluppatore abbia a disposizione sei ore potenziali al giorno da dedicare al lavoro sul progetto, al lordo degli eventi Scrum pianificati e di altri impegni.
Ecco come funziona il calcolo della capacità su 10 giorni lavorativi:
| Calcolo della capacità | Ore |
|---|---|
| Capacità di base: 6 sviluppatori × 10 giorni × 6 ore | 360 |
| Ferie secondo il piano: 1 sviluppatore assente per 2 giorni | −12 |
| Servizio di reperibilità: 1 sviluppatore con disponibilità al 50% | −30 |
| Eventi Scrum: 8 ore per sviluppatore | −48 |
| Capacità disponibile | 270 |
| Riservate il 20% per il lavoro imprevisto | −54 |
| Capacità disponibile per il lavoro pianificato | 216 |
Ora disponi di 216 ore per il lavoro pianificato, dopo aver riservato un margine di sicurezza indicativo del 20%. In pratica, sceglieresti tale margine in base alla quantità di lavoro non pianificato che ha interrotto i sprint precedenti.
Scegli il lavoro che supporta l’obiettivo dello sprint
Una volta stabilita la capacità, gli sviluppatori esaminano con il titolare del prodotto gli elementi del backlog relativi al checkout.
Ecco una selezione esemplificativa basata sulle stime iniziali dello sforzo a livello di attività:
| Elemento del backlog | Stima del lavoro richiesto |
|---|---|
| Crea il modulo di pagamento con scheda | 48 ore |
| Integra il provider di servizi di pagamento | 88 ore |
| Gestisci i pagamenti non andati a buon fine e gli errori di convalida | 50 ore |
| Aggiungi la conferma del pagamento e l’invio della ricevuta | 24 ore |
| Lavoro totale pianificato | 210 ore |
Queste stime lasciano 6 ore di margine all’interno del tempo previsto per il lavoro pianificato, oltre alle 54 ore di riserva per il lavoro imprevisto. Il team ha inoltre inserito nel product backlog il miglioramento di una dashboard di reportistica. Sebbene sia importante, non contribuisce direttamente all’obiettivo di consegna. Il Product Owner e gli sviluppatori concordano di rimandarlo a uno sprint futuro.
Adatta il piano quando qualcosa cambia
Il sesto giorno, il provider di servizi di pagamento introduce una modifica all’API che compromette parte dell’integrazione. Gli sviluppatori analizzano la situazione e stimano il lavoro aggiuntivo necessario.
Anziché procedere con l’ordine di lavoro originale, discutono l’impatto con il Product Owner. Se la correzione rientra nella capacità residua, possono assegnarle la priorità e rinviare la formattazione facoltativa delle ricevute o un’altra attività a priorità inferiore. La conferma del pagamento e altre attività essenziali devono comunque soddisfare la Definizione di Terminato.
Se la correzione è più ampia del previsto, sarà necessario rivalutare l’ambito rimanente e verificare se l’obiettivo dello sprint sia ancora raggiungibile.
Il team potrebbe concludere lo sprint con un numero di elementi del backlog completati inferiore a quanto previsto inizialmente. Tuttavia, se i clienti riescono a completare il checkout come previsto e il lavoro soddisfa la Definizione di Terminato, l’obiettivo dello sprint è stato raggiunto.
Esempi di obiettivi di sprint per altri team
È possibile applicare lo stesso approccio di pianificazione anche al lavoro al di fuori dello sviluppo software, sebbene Scrum sia di per sé un framework specifico con responsabilità ed eventi ben definiti.
Ad esempio, un team di marketing potrebbe fissare un obiettivo del tipo: “Pubblicare la pagina di destinazione del webinar e consentire ai visitatori di registrarsi senza assistenza manuale”. Un team operativo potrebbe puntare a: “Garantire che ogni dipendente della prossima coorte di nuovi assunti disponga dell’attrezzatura e dell’accesso al sistema necessari fin dal primo giorno”.
Entrambi gli obiettivi descrivono i risultati che possono guidare le decisioni del team durante lo sprint. Gli elementi del backlog e i piani di consegna varieranno, ma il team deve comunque valutare la propria capacità e concordare quale sia l’esito positivo di una consegna.
Errori comuni nella pianificazione dello sprint e come risolverli
La pianificazione dello sprint può incontrare difficoltà quando i team utilizzano gli story point per valutare le prestazioni individuali, presentano nella riunione elementi del backlog poco chiari, assegnano il lavoro in modo troppo rigido o trascurano i requisiti di test e le dipendenze esterne.
Bastano pochi aggiustamenti per aiutarti a individuare questi problemi prima che compromettano la consegna.
| Errore | Perché questo crea problemi | Come risolvere il problema |
| L'uso degli story point per misurare le prestazioni individuali | Confrontare gli sviluppatori in base ai punti completati può incoraggiare stime gonfiate o l’evitamento di lavori complessi. | Concentra gli story point sulle previsioni a livello di team. Esamina il lavoro completato nel corso di diversi sprint e discuti le variazioni delle stime durante la fase di raffinamento. Valuta le prestazioni individuali in base alla qualità del codice, alla collaborazione e ai risultati. |
| Inserire nel piano gli elementi del backlog non chiari | L'assenza di criteri di accettazione o la presenza di domande tecniche senza risposta trasformano il piano in una discussione su cosa realizzare, lasciando meno tempo per pianificare la consegna. | Risolvi eventuali dubbi durante il raffinamento del backlog, in modo che gli sviluppatori possano formulare una previsione ragionevole. Se permangono incertezze, prendi in considerazione un lavoro più piccolo e meglio compreso. Punta a ottenere una chiarezza sufficiente per prendere una decisione, piuttosto che a specifiche perfette. |
| Assegnare ogni attività a una persona prima dell’inizio del lavoro | Gli incarichi fissi rendono più difficile adattarsi quando cambiano le priorità o quando uno sviluppatore finisce in anticipo mentre un altro ha bisogno di aiuto. | Lascia che siano gli sviluppatori a organizzare il lavoro. Concorda le responsabilità immediate e il contributo degli specialisti, poi consenti ai membri del team di assumere, affiancarsi o ridistribuire le attività durante lo sprint. Mantieni la visibilità del lavoro per tutto il team. |
| Lasciare irrisolte le dipendenze esterne | La mancanza di credenziali API, revisioni di sicurezza o deliverable di un altro team può costringere il team ad attendere il completamento del lavoro su cui non ha alcun controllo. | Prima di finalizzare lo sprint backlog, identifica gli input necessari, chi li coordinerà e quando sono previsti. Se una dipendenza critica rimane incerta, valuta un elemento alternativo o un ambito più ristretto che il team possa portare a termine in modo autonomo. |
Se gli stessi problemi continuano a presentarsi in più sprint, portali alla retrospettiva dello sprint e concorda una modifica da testare durante lo sprint successivo. Questi modelli di retrospettiva dello sprint possono aiutarti a registrare le osservazioni e le azioni di follow-up.
Al termine dello sprint, utilizza la riunione di revisione dello sprint per esaminare l’incremento completato insieme alle parti interessate e discutere quali attività il team dovrebbe affrontare successivamente.
Come condurre la pianificazione dello sprint in ClickUp
La pianificazione dello sprint richiede un lavoro richiesto maggiore quando le attività, le stime di capacità e le decisioni di pianificazione sono sparse su diversi strumenti. ClickUp riunisce tutte queste informazioni, consentendo al team di esaminare il lavoro in relazione alla capacità e di rivedere le decisioni di pianificazione quando il piano cambia.
Inizia con il modello di pianificazione dello sprint agile di ClickUp. Le sue viste relative al backlog, allo stato di sviluppo e alle risorse ti aiutano a esaminare il lavoro imminente e a prepararti alla discussione di pianificazione.
Ecco come affrontare le decisioni chiave:
- Rendi più facile la valutazione del lavoro imminente: conserva i requisiti, i criteri di accettazione, le priorità e le dipendenze in un elenco di attività di ClickUp in sospeso. Questi dettagli aiutano gli sviluppatori a discutere l’ambito di lavoro e a stimarne il lavoro richiesto prima di selezionare le attività. Aggiungi le attività scelte allo sprint una volta che il team ha concordato il piano
- Definisci un periodo di pianificazione costante: configura la durata dello sprint e le date di inizio in ClickUp Sprints. Utilizza i punti dello sprint o le durate stimate per valutare il lavoro richiesto e aiutare il team a stabilire la quantità di lavoro che può assumersi
- Verifica se il carico di lavoro è adeguato: confronta il lavoro assegnato con la capacità di ciascuna persona nella vista “Carico di lavoro” di ClickUp. Esamina eventuali squilibri nel carico di lavoro e discuti eventuali modifiche prima di finalizzare la previsione.
- Mantieni l’ordine del giorno e le decisioni strettamente legati al lavoro: utilizza ClickUp Docs per l’ordine del giorno con i tempi, l’obiettivo proposto per lo sprint e i link alle attività pertinenti. Registra le decisioni relative all’ambito di lavoro e le questioni irrisolte durante la sessione, in modo che il team possa riesaminarle man mano che il lavoro procede
- Registra la discussione di pianificazione: ClickUp AI Notetaker può registrare le riunioni su Zoom, Google Meet, Microsoft Teams o SyncUps e salvare un riassunto, le decisioni chiave e le azioni da intraprendere in un documento. Rivedi gli appunti, quindi aggiorna le attività dello sprint con i follow-up concordati
- Utilizza i dati sullo stato di avanzamento per orientare le discussioni: aggiungi le schede "Sprint Burndown" o "Burnup" alle dashboard di ClickUp per esaminare il lavoro completato e lo sforzo residuo. Quando lo stato di avanzamento si discosta dal piano, esamina le attività pertinenti per individuare eventuali ritardi o modifiche all'ambito che richiedono attenzione
Prima della prossima sessione di pianificazione, chiedi a Brain²: «Quali dipendenze irrisolte sono emerse durante la nostra ultima sessione di pianificazione dello sprint?». Brain è in grado di recuperare il contesto dalle note della riunione registrate. Confronta tali dettagli con le attività attuali prima di utilizzarli per definire la prossima previsione.
Prezzi di ClickUp
Ideale per: team Scrum che gestiscono più sprint, dipendenze condivise e carichi di lavoro variabili e che necessitano di gestione del backlog, pianificazione della capacità e reportistica sullo stato di avanzamento in un unico spazio di lavoro. È inoltre una soluzione adatta ai team che coordinano il lavoro degli sprint con progetti di prodotto o aziendali più ampi.
Da saltare se: il tuo team ha bisogno solo di una bacheca Scrum di base con un backlog ridotto e reportistica minima. La flessibilità di ClickUp comporta decisioni relative alla configurazione delle impostazioni dello sprint, delle visualizzazioni e dei campi. Alcune funzionalità avanzate di reportistica e automazione dello sprint richiedono inoltre piani di livello superiore, che potrebbero non essere necessari per un flusso di lavoro semplice.
Quanto dovresti pianificare prima dell’inizio di uno sprint?
Una sessione di pianificazione dello sprint dovrebbe fornire al team la chiarezza necessaria per iniziare a lavorare.
Il programma con tempistiche e l’esempio di calcolo della capacità riportati sopra costituiscono un punto di partenza. Adattali al carico di lavoro del team, quindi confronta le previsioni con il lavoro completato e le interruzioni per migliorare la pianificazione successiva.
In ClickUp, puoi collegare le note di pianificazione alle attività dello sprint e aggiornare lo sprint backlog man mano che il lavoro cambia. Il team può fare riferimento al piano concordato quando deve decidere cosa modificare.
Domande frequenti sulla pianificazione dello sprint
Qual è la differenza tra la pianificazione dello sprint e la pianificazione del rilascio?
La pianificazione dello sprint si concentra su ciò che il tuo team intende realizzare durante uno sprint e su come consegnerà quel lavoro. La pianificazione del rilascio considera un orizzonte temporale più ampio, ad esempio quali funzionalità/funzioni potrebbero essere disponibili nell’arco di diversi sprint e quando gli utenti potrebbero riceverle. Le previsioni relative al rilascio possono cambiare man mano che i team acquisiscono ulteriori informazioni, mentre ogni obiettivo dello sprint guida il lavoro all’interno dello sprint stesso.
Hai bisogno di una “Definizione di pronto” per la pianificazione dello sprint?
No. Scrum non richiede una definizione formale di “pronto”. Alcuni team ne utilizzano una per stabilire aspettative condivise relative agli elementi del backlog prima della selezione, quali requisiti chiari, ambito gestibile e dipendenze note. Assicurati che questi criteri siano sufficientemente flessibili da fornire supporto alla discussione senza impedire al team di perfezionare gli elementi quando necessario.
È possibile annullare uno sprint dopo il piano?
Sì. Solo il Product Owner può annullare uno sprint, e l’annullamento è un’opzione quando l’obiettivo dello sprint diventa obsoleto, magari perché le priorità aziendali o le condizioni di mercato sono cambiate in modo significativo. Una attività difficile o una stima imprecisa, di per sé, non giustificano necessariamente l’annullamento.
Qual è la differenza tra uno sprint e l’agilità?
L’Agile è un approccio più ampio alla gestione del lavoro basato sui valori e sui principi del Manifesto Agile. Uno sprint è un periodo fisso di un mese o meno all’interno del framework Scrum, durante il quale un team lavora per raggiungere un obiettivo dello sprint e crea un incremento utilizzabile. È possibile seguire i principi Agile senza ricorrere agli sprint. Il Kanban, ad esempio, fornisce supporto per un flusso continuo di lavoro senza richiedere iterazioni di durata fissa.
Uno sprint può avere più obiettivi?
Scrum definisce l’obiettivo dello sprint come l’unico obiettivo dello sprint. È possibile selezionare elementi del backlog che supportano altre priorità, purché non mettano a rischio tale obiettivo. Se il vostro team ha regolarmente bisogno di diversi obiettivi non correlati, discutete se il lavoro contribuisca a un risultato condiviso più ampio o se sia necessario risolvere le priorità in conflitto prima della pianificazione.
È opportuno stimare i bug in story point durante la pianificazione dello sprint?
Gli story point sono facoltativi in Scrum, anche per i bug. I team che stimano i bug dovrebbero concordare quando e perché farlo. I difetti noti possono essere valutati durante la pianificazione, mentre i bug scoperti durante lo sviluppo potrebbero rientrare nel lavoro già necessario per soddisfare la Definizione di Terminato. Evita di conteggiare due volte il lavoro richiesto.