Sprint nello sviluppo mobile: essenza, durata e pianificazione

Cos'è uno sprint nello sviluppo?

Sprint è un timebox di durata fissa al termine del quale il team fornisce un incremento del prodotto pronto all'uso. Il concetto di sprint è il fondamento di Scrum, ma viene utilizzato anche in altri framework Agile. Nello sviluppo mobile, un incremento è un build dell'applicazione che può essere installato su un dispositivo, testato e mostrato agli stakeholder. Uno sprint non può essere esteso — se le attività non sono completate, vengono spostate nello sprint successivo.

La caratteristica principale di uno sprint è la durata fissa. Il team non modifica l'obiettivo dello sprint dopo l'approvazione. Questo offre prevedibilità: gli stakeholder sanno quando riceveranno il risultato. All'interno dello sprint, il team decide come distribuire il lavoro. Lo Scrum Master protegge il team da interferenze esterne — non vengono aggiunte nuove attività allo sprint corrente. Secondo la Scrum Guide 2025, questo è l'unico modo per mantenere un ritmo di sviluppo sostenibile.

Uno sprint consiste in quattro eventi obbligatori: Sprint Planning, Daily Scrum (sincronizzazione quotidiana), Sprint Review (dimostrazione del risultato), Sprint Retrospective (analisi del processo). Tra questi c'è il lavoro principale: implementazione delle attività, test, code review. Durata di ogni evento è direttamente proporzionale alla lunghezza dello sprint: per uno sprint di 2 settimane, Planning dura 4 ore, Review 2 ore, Retro 1,5 ore, Daily 15 minuti. In totale, i rituali richiedono circa 8 ore per sprint — il 10% del tempo di lavoro del team.

Rituali Scrum dello sprint

Rituali Scrum (cerimonie/eventi) sono riunioni strutturate del team all'interno dello sprint. Sprint Planning all'inizio, Daily Scrum ogni giorno, Sprint Review e Retrospective alla fine. Tutti gli eventi hanno un timebox. Lo Scrum Master garantisce il rispetto del timebox e della concentrazione. L'intero team Scrum partecipa a ogni rituale: Product Owner, Scrum Master, sviluppatori. L'eccezione è il Daily Scrum (partecipano solo gli sviluppatori, PO e SM sono opzionali).

Il collegamento dei rituali con le fasi dello sprint: Planning stabilisce la direzione (cosa e come fare), Daily sincronizza (chi sta facendo cosa, quali blocchi ci sono), Review mostra il risultato (cosa è stato fatto, cosa no), Retrospective migliora il processo (come rendere migliore il prossimo sprint). Saltare la retrospective è l'errore più comune del team: quando le scadenze sono strette, Retro viene sacrificata per prima. Questo porta alla stagnazione dei processi e alla ripetizione degli stessi errori. La ricerca di Scrum.org (2025) mostra che i team che fanno Retro ogni 2 settimane migliorano la velocità del 35% più velocemente.

Sprint Planning: pianificazione dell'iterazione

Sprint Planning è una riunione del team all'inizio dello sprint in cui viene determinato cosa verrà fatto e come. Il Product Owner presenta le attività prioritarie dal Product Backlog. Il team stima la capacità (tempo disponibile considerando ferie, riunioni, debito tecnico) e seleziona le attività che può completare durante lo sprint. Il risultato del Planning è lo Sprint Goal (obiettivo dello sprint) e lo Sprint Backlog (elenco delle attività). Lo Sprint Goal viene formulato come una frase breve: “Implementare la schermata di ordine e l'integrazione del pagamento tramite SBP.”

Velocity è la velocità del team misurata in story point per sprint. Media degli ultimi 3-5 sprint. Secondo Scrum.org (2025), un team di 5 sviluppatori mobili (3 Android + 2 iOS) ha una velocità di 25-40 SP per sprint di 2 settimane. Il Planning utilizza la velocità come limite superiore — prendono il 10-15% in meno per tenere conto di attività impreviste (code review, incidenti, aiuto ad altri team). Capacità vs Velocità: la capacità sono le “ore-persona”, la velocità sono gli “story point”. La capacità tiene conto di ferie, malattie, riunioni. Il tasso di perdita tipico è del 25-30% del tempo di lavoro speso in attività non di codice.

Il Planning è diviso in due parti: “cosa” (PO descrive le attività, il team chiarisce) — 2 ore, e “come” (il team decompone e stima) — 2 ore. Per i progetti mobili, nel “come” si discute: compatibilità con versioni Android/iOS, necessità di feature flag, impatto sulle dimensioni di APK/IPA, nuovi permessi. Tecnica del Planning Poker viene utilizzata per la stima: ogni sviluppatore fornisce la propria stima in story point (1, 2, 3, 5, 8, 13). Una discrepanza superiore a 2 unità innesca una discussione delle ragioni. Questo rivela rischi nascosti nella fase di pianificazione, non a metà dello sprint.

Esecuzione dello sprint: Daily Standup e monitoraggio

Daily Scrum (Standup) è una riunione quotidiana di 15 minuti per la sincronizzazione del team. Ogni partecipante risponde a tre domande: “Cosa è stato fatto ieri?”, “Cosa ho intenzione di fare oggi?”, “Quali blocchi ho?” Il Daily non è un rapporto di stato per il manager, ma uno strumento di auto-organizzazione del team. Se durante il Daily si scopre che due sviluppatori stanno lavorando alla stessa attività — è un segnale di riorganizzazione. Importante: il Daily non risolve i problemi ma li identifica — per risolverli viene convocata una riunione separata dopo il Daily.

Scrum Board (tabellone dello sprint) è una visualizzazione dello Sprint Backlog. Colonne: To Do / In Progress / In Review / Done. Ogni attività si sposta sul tabellone. Il Burndown Chart è un grafico del lavoro rimanente per giorno dello sprint. Il burndown ideale è una linea retta dal SP totale a 0. Il burndown reale è un grafico a gradini che riflette il completamento delle attività. Un burndown in calo (sotto la linea ideale) significa che siamo in ritardo. Segnale di problema: se a metà sprint è stato completato meno del 30% delle attività — è necessario un aggiustamento. Potrebbero non essere stati considerati i rischi o le attività sono state sovrastimate.

Per lo sviluppo mobile, il monitoraggio dello sprint è influenzato da fattori specifici: tempo di build (la build del progetto Android in CI può richiedere 30+ minuti), attesa della moderazione dell'App Store / Google Play (se è necessario rilasciare un build ai tester tramite TestFlight), compatibilità con diversi dispositivi (test su 10+ modelli richiede tempo). Suggerimento: riservare 1 giorno di buffer alla fine dello sprint per i test finali e l'assemblaggio del build di rilascio. Questo riduce il rischio di sprint incompleto del 40% secondo Mind the Product (2025).

Sprint Review e Retrospective

Sprint Review è una dimostrazione dell'incremento agli stakeholder. Il team mostra un build funzionante dell'applicazione, non diapositive. La durata è di 2 ore per uno sprint di 2 settimane. Il Product Owner verifica la conformità ai Acceptance Criteria. Gli stakeholder forniscono feedback che può influenzare il Product Backlog. Il Review non è un rapporto ma un dialogo: gli stakeholder possono fare domande e suggerire modifiche. Regola chiave: lo Sprint Review riguarda il prodotto, non il processo. Mostra cosa è stato raggiunto, non come è stato fatto.

Sprint Retrospective è una riunione interna del team per analizzare lo sprint passato. Formato: Start Doing (cosa iniziare a fare), Stop Doing (cosa smettere di fare), Continue Doing (cosa continuare a fare). La durata è di 1,5 ore per uno sprint di 2 settimane. La Retrospective è uno spazio sicuro per discutere problemi. Regola: in Retro non si discutono dettagli tecnici (ci sono riunioni tecniche per quello). Solo processo, comunicazione, strumenti, cultura. Lo Scrum Master facilita la riunione e si assicura che ogni partecipante parli.

Il risultato della Retrospective sono 1-3 miglioramenti per lo sprint successivo. Se il team ha identificato il problema “Il code review richiede troppo tempo” — action item: “Impostare SLA per la revisione — 4 ore. Se la revisione non viene eseguita in tempo — lo sviluppatore ricorda in Slack.” Action Items devono essere specifici, misurabili e assegnati a una persona specifica. Secondo Atlassian (2025), i team che eseguono i propri action item di Retro migliorano la velocità del 15-25% in 3-4 sprint. Quelli che non lo fanno — ristagnano.

Come scegliere la durata dello sprint

2 settimane sono lo standard per lo sviluppo mobile. L'equilibrio ottimale tra prevedibilità e flessibilità. Abbastanza tempo per: pianificare, implementare 3-5 funzionalità medie, testare, mostrare risultati. 1 settimana è per team con elevata maturità dei processi e CI/CD. Richiede decisioni rapide, burocrazia minima. Adatto per startup in fase iniziale che devono sperimentare rapidamente. Svantaggio: overhead elevato per i rituali (Planning + Review + Retro ogni settimana = 7,5 ore).

3-4 settimane sono per progetti complessi che coinvolgono integrazione hardware (wearable, IoT, dispositivi BLE), moderazione lunga degli store o migrazioni importanti (ad esempio, passaggio da RxJava a Coroutines). Gli sprint lunghi forniscono più tempo per i test ma aumentano il rischio dell'“effetto cascata” — il team perde flessibilità Agile. Raccomandazione della Scrum Guide: non superare 1 mese. Se lo sprint è più lungo, ci sarà troppo contesto al Review e gli stakeholder non potranno fornire feedback di qualità.

Problemi tipici degli sprint

Problema 1: Scope Creep. A metà dello sprint, il Product Owner aggiunge una nuova attività “urgente e importante”. Il team accetta — e lo sprint fallisce. Soluzione: lo Sprint Goal è un contratto. Qualsiasi modifica richiede una revisione dello Sprint Goal, possibile solo in casi di emergenza. La nuova attività va nel Product Backlog e nello sprint successivo. Se l'attività è davvero critica — il vecchio Sprint Goal viene annullato, lo sprint viene ripiantificato, ma questa è un'eccezione, non una pratica. La frequenza di scope creep superiore a una volta ogni 3 sprint è segno di un Product Owner debole.

Problema 2: Attività incomplete. Alla fine dello sprint, il 50% delle attività sono In Progress, il 20% In Review, solo il 30% Done. Ragioni: capacità sovrastimata, complessità sottostimata, bug non pianificati. Soluzione: analizzare la causa in Retro. Se sistematicamente non si riesce a tenere il passo — non aumentare il numero di attività nel Planning, diminuirle. I team che prendono il 20% in meno di attività mostrano un tasso di completamento più elevato (80%+ contro 50-60%). Checklist per il Planning: per ogni attività, verificare Acceptance Criteria, Definition of Ready e dipendenza con altre attività.

Problema 3: Retro formale. Il team fa Retro solo per formalità — 15 minuti, frasi generiche, nessun action item. Soluzione: cambiare il formato di ogni Retro. Metodi: Sailboat (cosa rallenta, cosa accelera), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Assegnare action item con scadenze e responsabili. All'inizio della Retro successiva, verificare l'esecuzione degli action item precedenti. Secondo Atlassian (2025), i team che usano diversi formati di Retro generano il 50% in più di intuizioni utili.