Pianificazione sprint: best practice Agile

Fondamenti della pianificazione

Una buona pianificazione dello sprint richiede metodo: analizzare gli sprint precedenti, valutare quanto il team può davvero sostenere e definire gli obiettivi in modo chiaro. Maggiori informazioni: Software di gestione dei progetti IT per team IT.

1. La preparazione per la pianificazione dovrebbe iniziare con largo anticipo. Il Product Owner prepara il backlog e ne fissa le priorità almeno un giorno prima della riunione. Il team di sviluppo deve poter leggere le user story in anticipo e fare le domande che servono a chiarirle.
2. La regola classica di allocazione: due ore di pianificazione per ogni settimana di sprint. Per uno sprint di due settimane fanno quattro ore — anche se spesso conviene dividere questo tempo in più sessioni brevi invece di un'unica riunione lunga.

Fase di preparazione

Senza una buona preparazione, la pianificazione dello sprint non migliora. Questa fase viene spesso sottovalutata. Eppure decide la riuscita dell'intero processo.

• Definition of Ready (DoR) fissa i criteri che una user story deve soddisfare prima di entrare in uno sprint. Ogni story dovrebbe avere criteri di accettazione chiari, una stima di complessità e le dipendenze da altri compiti già individuate. Se il DoR non viene rispettato, la pianificazione diventa caotica e il team passa il tempo a chiarire le story invece di pianificare il lavoro.
• Backlog refinement va fatto con regolarità, non solo a ridosso della pianificazione dello sprint. Dedicare a questo lavoro il 10% del tempo dello sprint è una pratica standard. Il team può tenere brevi sessioni di refinement più volte alla settimana e preparare un po' alla volta le story degli sprint successivi.
• L'analisi della Velocity dà al team un quadro preciso di quanto riesce davvero a consegnare. Conta la Velocity media degli ultimi 3-5 sprint, ma contano anche i fattori che possono pesare sullo sprint in arrivo: ferie già programmate, festività, debito tecnico accumulato, dipendenze esterne.

Sessioni di pianificazione

La pianificazione dello sprint si divide in due momenti. Prima si decide cosa verrà consegnato nello sprint, poi come verrà realizzato il lavoro scelto. Le due fasi richiedono input diversi e producono risultati diversi — mescolarle le indebolisce entrambe.

1. Il team, insieme al Product Owner, definisce l'obiettivo dello sprint che tiene insieme tutte le user story scelte. L'obiettivo deve essere specifico, misurabile e sensato per tutti i partecipanti. Obiettivo inefficace: "Migliorare l'esperienza utente." Obiettivo efficace: "Gli utenti potranno registrarsi attraverso i social media con un clic."
2. Il team di sviluppo scompone le story scelte in compiti e li stima in ore. È in questo passaggio che emergono complessità e dipendenze nascoste, invisibili a livello di story. Nessun compito dovrebbe superare le 8 ore — quelli più lunghi vanno divisi ancora in sottocompiti.

Ruoli e responsabilità

La pianificazione funziona quando ogni partecipante conosce il proprio ruolo e resta al suo interno.

• Lo Scrum Master facilita il processo, fa rispettare i timebox e aiuta il team a decidere. Lo Scrum Master non impone soluzioni. Pone le domande giuste e tiene le discussioni sul concreto.
• Il Product Owner risponde delle priorità del backlog e decide quali funzionalità realizzare per prime. Deve saper spiegare il valore di business di ogni story e rispondere alle domande del team con abbastanza precisione da permettere la stima.
• Il team di sviluppo si impegna a consegnare i risultati. Questo impegno deve nascere dal team, non essere assegnato dall'esterno — un impegno preso dal team genera un livello di motivazione e di responsabilità diverso da quello degli obiettivi imposti.

Errori comuni

• La sopravvalutazione delle capacità è l'errore più frequente nella pianificazione dello sprint. I team prendono regolarmente più lavoro di quanto riescano a chiudere, soprattutto all'inizio di un progetto o dopo uno sprint andato bene. La regola pratica è promettere meno e consegnare di più. Gli impegni mancati minano la fiducia degli stakeholder e abbassano la motivazione del team negli sprint successivi.
• L'assenza di buffer di tempo è un errore strutturale critico. Il piano dello sprint dovrebbe lasciare il 10-20% di tempo di riserva per compiti imprevisti, bug e richieste di supporto tecnico. Questa riserva non va riempita in anticipo con altre story — serve proprio ad assorbire il lavoro non pianificato che arriva in ogni sprint.
• Ignorare le dipendenze crea blocchi a metà sprint. Tutte le dipendenze esterne vanno individuate e risolte in fase di pianificazione. Se un compito dipende da un altro team o da un fornitore esterno, le scadenze si concordano prima e le conferme si ottengono prima che lo sprint cominci.

Monitoraggio del processo

Nella pratica Agile matura, anche il processo di pianificazione va migliorato di continuo. Nelle retrospettive il team dovrebbe guardare ai risultati dello sprint e, separatamente, alla qualità della pianificazione, trattandola come una variabile di input a sé.

Metriche per l'analisi:

• Accuratezza della stima — confronto tra tempo pianificato e tempo effettivamente speso per story e compito
• Percentuale di story completate — la quota di story prese in carico nello sprint e consegnate entro la sua chiusura
• Numero di modifiche nello sprint dopo la pianificazione — misura quanto è stabile il piano e quanto sono chiari i requisiti
• Tempo dedicato alla pianificazione — confrontato con l'allocazione standard per scoprire se si investe cronicamente troppo o troppo poco

I grafici Burndown seguono l'avanzamento per tutto lo sprint e fanno emergere i problemi in tempo per correggere la rotta. Se il grafico mostra che il team non chiuderà il lavoro previsto, bisogna intervenire. Si ridefiniscono le priorità dei compiti rimasti oppure si tolgono dallo sprint le user story meno prioritarie.

Adattare la pianificazione

• I team remoti richiedono adattamenti specifici alla pianificazione dello sprint. Servono strumenti di collaborazione adatti, e bisogna fare in modo che tutti i partecipanti a distanza abbiano davvero spazio per intervenire. Nei team distribuiti, qualche sessione breve al posto di una lunga riunione dà di solito più coinvolgimento e un risultato migliore.
• I grandi programmi con più team richiedono coordinamento a livello di programma. Scrum of Scrums o SAFe (Scaled Agile Framework) offrono meccanismi strutturati per sincronizzare la pianificazione tra team che condividono dipendenze.
• I progetti di manutenzione — dove buona parte dello sprint se ne va in supporto e correzione di bug — richiedono una riserva di capacità esplicita per il lavoro non pianificato. Un'allocazione standard del 30-50% della capacità dello sprint per il supporto, con il resto dedicato alle nuove funzionalità, evita i mancati rilasci che nascono quando il supporto viene trattato come overhead invece che come capacità pianificata.

Articoli correlati:

Per i framework di gestione dei progetti e il bilanciamento dei vincoli, leggi Il triangolo della gestione dei progetti: Bilanciare ambito, tempo e costo.

Per una panoramica pratica delle bacheche Kanban e della gestione visiva del flusso di lavoro, leggi Cos'è una bacheca Kanban? Una guida alla gestione visiva del flusso di lavoro.

Per capire come i team Agile usano le persona per restare vicini alle esigenze reali degli utenti, leggi Persona Agile: Migliorare lo sviluppo incentrato sull'utente nei progetti Agile. Scopri di più: Bacheca Kanban.

Conclusione

Pianificare bene uno sprint richiede metodo e un miglioramento continuo, da praticare in modo deliberato e non a progetto finito. Le retrospettive offrono lo strumento per farlo. Lì si analizzano i risultati dello sprint e anche le scelte di pianificazione che li hanno prodotti. Così la pianificazione stessa entra nello stesso ciclo di miglioramento iterativo che Agile applica allo sviluppo del prodotto.