Daily Standup — cos'è, regole della riunione quotidiana e benefici

Cos'è il Daily Standup?

Daily Standup — una breve riunione del team Scrum che si tiene ogni giorno lavorativo allo stesso orario e luogo. Timebox — 15 minuti. È conosciuto con diversi nomi: Daily Scrum (nella Guida Scrum), sincronizzazione mattutina, morning circle, daily. L'obiettivo è sincronizzare il team, identificare i blocchi e regolare i piani della giornata. Il daily non è un rapporto per il manager, ma uno strumento di auto-organizzazione del team. Il team decide come strutturare la riunione, non il manager.

L'origine del termine “standup“ deriva dalla pratica di stare letteralmente in piedi durante la riunione: i partecipanti si riuniscono intorno alla lavagna e non si siedono. Questo crea un senso di temporaneità — nessuno vuole stare in piedi più di 15 minuti. Lo standup fisico è ancora utilizzato dal 60% dei team (secondo Scrum.org 2025), mentre il resto è passato al formato remoto tramite Zoom, Slack Huddle o Teams. Nel formato remoto, è importante mantenere la disciplina: telecamere accese, nessun multitasking, preparazione anticipata delle risposte.

La Guida Scrum 2025 definisce il Daily Scrum come un evento per i Developers (sviluppatori). Il Product Owner e lo Scrum Master possono partecipare ma non sono obbligati. Se PO o SM partecipano, non dirigono la riunione. Il team sceglie la propria struttura: le classiche tre domande o un board walk. Punto chiave: il daily riguarda l'ispezione del progresso verso il Sprint Goal, non lo stato di ogni singolo task. Se la riunione si trasforma in un elenco di task sulla lavagna, il team ha perso il focus sul Sprint Goal.

Le tre domande del Daily Standup

Domanda 1: “Cosa ho fatto ieri per raggiungere il Sprint Goal?“ — un breve riepilogo dei task completati. Non “ho lavorato su APP-123“, ma “finito la schermata di login, PR inviato per review“. La formulazione “per raggiungere il Sprint Goal“ è intenzionale: collega il lavoro quotidiano all'obiettivo generale dello sprint. Se uno sviluppatore non vede la connessione tra il suo task e il Sprint Goal, è un segnale che il task potrebbe non essere necessario nello sprint corrente. Nello sviluppo mobile, i risultati di ieri includono non solo codice ma anche test, documentazione e configurazione CI/CD.

Domanda 2: “Cosa ho intenzione di fare oggi per raggiungere il Sprint Goal?“ — il piano per la giornata corrente. Non più di 2-3 elementi. Uno sviluppatore potrebbe dire: “Oggi finirò la ViewModel per la schermata del profilo, scriverò test unitari e farò un build su un dispositivo reale.“ Se il piano corrisponde a quello di “ieri“, è un segnale che il task è troppo grande e deve essere scomposto. La regola dei due giorni: se un task non viene completato entro 2 giorni di lavoro, dovrebbe essere suddiviso in sotto-task, altrimenti ristagnerà in In Progress per settimane.

Domanda 3: “Quali blocchi ostacolano il mio progresso?“ — la domanda più importante. Un blocco è qualcosa che lo sviluppatore non può risolvere da solo: attendere una review (se lo SLA di review è stato superato), un emulatore che non funziona, un'API non pronta, necessità di accesso al repository. Importante: i blocchi devono essere nominati ma non risolti durante il daily. Dopo la riunione, lo sviluppatore e lo Scrum Master / manager organizzano la risoluzione del blocco. Secondo Scrum.org (2025), il 70% dei blocchi dei team mobile è correlato a: attesa di review (30%), indisponibilità di dispositivi di test (20%) e dipendenze dal backend (20%).

Come condurre correttamente uno standup

Orario e luogo. Il daily si tiene alla stessa ora ogni giorno — di solito all'inizio della giornata lavorativa (9:00-10:00). Per i team distribuiti, si sceglie un orario comodo per tutti i fusi orari. Durata — rigorosamente 15 minuti. Un timer è obbligatorio. Se il team non termina in tempo, il problema non è il daily ma il processo: o ci sono troppi partecipanti o i task vengono discussi invece di essere solo nominati. La regola del ping-pong: ogni partecipante parla per non più di 60 secondi. Dopo aver risposto, passa la parola al successivo.

Formato Board Walk. Un'alternativa alle tre domande: il team a turno sposta i task sulla lavagna Scrum commentando le modifiche. Uno sviluppatore prende il suo task da To Do, lo sposta in In Progress e dice: “Prendo APP-123 — la schermata dell'ordine, aggiungo il campo del codice promozionale.“ Il Board Walk fornisce una comprensione visiva del progresso e rivela i task “dimenticati“ — quelli che non si muovono da 3+ giorni. Board Walk è preferibile per i team distribuiti con Jira/Linear — tutti vedono la lavagna invece di ascoltare un monologo.

Per i team remoti: le telecamere devono essere accese — secondo Microsoft Research (2025), avere la telecamera accesa aumenta il coinvolgimento del 40%. Usate uno schermo condiviso con la lavagna dei task (Jira, Linear, Miro). Scrivete i blocchi nella chat — questo crea una traccia scritta. Incoraggiate le emoji di reazione (tranne per istruzione dell'utente — le emoji non vengono utilizzate) — un pollice in su sul messaggio di un collega. Dopo il daily, prendete 2-3 minuti per il parking lot: gli argomenti che richiedono una discussione separata vengono annotati in un elenco di riunioni di follow-up. Competenza chiave dello Scrum Master: fermare la discussione durante il daily e spostarla nel parking lot.

Errori tipici nelle riunioni

Errore 1: report di stato per il manager. Gli sviluppatori leggono a turno ciò che è scritto in Jira, il manager fa domande di chiarimento e la riunione dura 45 minuti. Soluzione: ricordare che il daily è per il team, non per il manager. Il manager può controllare lo stato sulla lavagna. Se il manager fa domande, spostatele in riunioni 1:1. Un team che trasforma il daily in un report di stato perde 2-3 ore a settimana su tutti i partecipanti. Con 8 sviluppatori, sono 16-24 ore-persona al mese — la perdita di uno sprint completo in un anno.

Errore 2: risolvere i problemi sul posto. Uno sviluppatore dice “Ho un bug con gRPC — il progetto non compila“ e l'intero team passa 20 minuti a discutere soluzioni. Soluzione: registrare il blocco nel parking lot e continuare il daily. Dopo la riunione, riunire le persone pertinenti (lo sviluppatore + chi può aiutare) per una discussione di 10 minuti. Secondo Basecamp (Shape Up), solo il 20% dei problemi scoperti durante il daily richiede una discussione dell'intero team. Il resto viene risolto da due sviluppatori in 10 minuti.

Errore 3: ritardi e assenze. Qualcuno arriva 5 minuti dopo l'inizio e bisogna ripetere tutto. Soluzione: stabilire la regola che “il daily inizia puntuale, i ritardatari non entrano“ o “il ritardatario paga una multa“ (caffè per il team). Ancora più rigoroso: il daily si tiene a un orario fisso; se qualcuno è sistematicamente in ritardo, è un problema di disciplina risolto in 1:1. Il daily è la sincronizzazione della giornata. Se uno sviluppatore lo perde, non è sincronizzato e rischia di fare il lavoro sbagliato per il team.

Errore 4: troppi partecipanti. Un team di 15+ persone, ciascuno parla un minuto — 20+ minuti in totale. Soluzione: dividere il team in sottogruppi per funzionalità/modulo. Ogni sottogruppo tiene il proprio daily (5-7 persone). Un rappresentante di ogni sottogruppo può partecipare a uno standup inter-team (se è necessaria sincronizzazione tra i team). Alternativa: uno standup asincrono tramite Slack/GeekBot dove ognuno scrive cosa ha fatto / prevede / blocchi.

Standup asincrono: alternative

Standup asincrono — un formato in cui i partecipanti scrivono le loro risposte in una chat (Slack, Telegram, Teams) o tramite un bot specializzato (GeekBot, Standuply, Status Hero) invece di una riunione orale. Adatto per team distribuiti con un dislivello orario di 3+ ore. Ogni partecipante risponde alle stesse tre domande entro un certo orario (ad esempio, entro le 11:00). Il bot raccoglie le risposte e pubblica un riepilogo nel canale comune. Vantaggi: flessibilità, traccia scritta, nessun problema di ritardo.

Svantaggi del formato asincrono: nessuna interazione dal vivo — i segnali non verbali vengono persi, è più difficile identificare i blocchi (uno sviluppatore potrebbe non scrivere di un problema). Un blocco scritto in una chat potrebbe passare inosservato fino alla fine della giornata. Secondo GitLab (2025), il 40% dei team che sono passati allo standup asincrono è tornato all'orale entro 3 mesi. Raccomandazione: usate un ibrido — 3 giorni di standup orale (lun, mer, ven) e 2 giorni asincrono (mar, gio). Oppure: standup orale 1-2 volte a settimana, asincrono nei giorni rimanenti.

Strumenti per lo standup asincrono: GeekBot (Slack) — fa le tre domande e pubblica un riepilogo; Standuply — si integra con Jira e fornisce monitoraggio automatico; Status Hero — raccoglie stati e genera report settimanali per la direzione. La scelta dello strumento dipende dalla cultura del team: nelle startup, un bot di Slack è sufficiente; negli ambienti aziendali, potrebbe essere necessario Standuply con integrazione nei processi aziendali. Regola importante: indipendentemente dal formato, le risposte devono essere visibili a tutto il team, non solo al manager. La trasparenza è un valore fondamentale di Agile.

Specificità del daily per i team mobile

Un team mobile affronta blocchi specifici durante il daily. Principali: build del progetto in CI (la build Gradle può richiedere 20+ minuti — se si rompe, lo sviluppatore perde un'ora a debuggare), attesa di TestFlight / Firebase App Distribution (pubblicare un build per i tester richiede 30-60 minuti), problemi con emulatori e simulatori (Android Emulator richiede KVM/HAXM, iOS Simulator solo su Mac). Il daily di un team mobile dovrebbe includere un rapido controllo dello stato del build: “Il build passa? Tutti i test sono verdi?“

Per i progetti multipiattaforma (Flutter, React Native), il daily può includere una domanda sullo stato del codice condiviso. Se due sviluppatori modificano contemporaneamente lo stesso file Dart e uno unisce le modifiche, il secondo si troverà ad affrontare conflitti. Consiglio: usate Board Walk con una lavagna segmentata per piattaforma (Android / iOS / Shared). Questo aiuta a visualizzare chi lavora dove e se le modifiche si sovrappongono. Per i progetti Flutter, usate una lavagna con colonne per Platform Channel, BLoC/Cubit, UI e Tests.

Prontezza per il rilascio è un altro punto specifico dello sviluppo mobile nel daily. 3-5 giorni prima del rilascio, aggiungete la domanda: “Il build è pronto per il rilascio? Tutti i metadati (icone, screenshot, descrizioni) sono aggiornati?“ Questo previene situazioni in cui gli sviluppatori finiscono di codificare il giorno del rilascio mentre il build e la pubblicazione richiedono altre 3-4 ore. Tracker di rilascio — una lavagna separata con una checklist: aggiornare versionCode/versionName, verificare ProGuard, firmare AAB, caricare nella console sviluppatore, scrivere le note di rilascio.