Modello di agenda per lo sprint planning per team di ingegneria

Perché gli sprint si sovraccaricano

Lo sprint planning ha un fallimento strutturale che i modelli non prevengono: i team selezionano il backlog dello sprint prima che qualcuno verifichi la capacità. Il risultato è uno sprint che sembrava realizzabile su una lavagna e che collassa entro mercoledì, quando due ingegneri sono assenti per metà settimana, un ticket triplica di scope e tre item avevano dipendenze non dichiarate da un servizio che il platform team sta riscrivendo.

La soluzione è semplice e quasi mai messa in pratica: impegnati sulla capacità prima di impegnarti sul lavoro. Il modello qui sotto apre con una revisione della capacità esattamente per questa ragione.

L'agenda (da copiare e incollare)

Durata: 2 ore per uno sprint di 2 settimane; 1 ora per uno sprint di 1 settimana
Formato: Facilitata, con il backlog visibile all'intero team

Sezione 1 — Obiettivo dello sprint (10 min)

Una frase: che aspetto ha uno sprint di successo visto dall'esterno?
L'obiettivo dovrebbe essere abbastanza specifico da permettere a qualsiasi membro del team di valutare a fine sprint se lo avete centrato
Rifiuta gli obiettivi che sono solo un elenco di ticket («finire il refactoring dell'auth e la pagina di billing») — quello è un backlog, non un obiettivo

Sezione 2 — Revisione della capacità (15 min)

Elenca ogni membro del team per nome
Per ciascuno: ferie pianificate, turni di on-call, riunioni ricorrenti, impegni esterni noti
Esprimi la capacità in story point o giorni disponibili — non in numero di persone
Questo numero è il tetto; non selezionare più lavoro di quanto ne supporti

Sezione 3 — Selezione del backlog (45 min)

Passa in rassegna gli item a più alta priorità del backlog rifinito
Per ogni candidato: il team ha abbastanza per iniziarlo, o ci sono domande aperte che necessitano risposta prima che lo sprint inizi? Le domande aperte appartengono alla coda di rifinitura, non allo sprint
Smetti di selezionare quando raggiungi l'80% della capacità; il restante 20% assorbe gli spillover e il lavoro non pianificato

Sezione 4 — Criteri di accettazione (20 min)

Per ogni item selezionato: dichiara il criterio che lo rende concluso
Se il team non riesce a dichiarare un criterio in 60 secondi, il ticket non è abbastanza rifinito — rimettilo nel backlog
Scrivilo nel ticket adesso, in sede di riunione; non affidarti al «lo aggiungeremo dopo»

Sezione 5 — Rischi e dipendenze (15 min)

Cosa potrebbe bloccare il raggiungimento dell'obiettivo dello sprint che il team non controlla?
Nomina il responsabile della dipendenza; fallo emergere ora, mentre c'è tempo per risolverlo prima di metà sprint
Le dipendenze irrisolte ottengono un responsabile nominato all'interno del team che le seguirà

Chiusura (15 min)

Conferma che l'obiettivo dello sprint sia ancora valido dato il lavoro selezionato
Assegna il verbalizzatore del riepilogo dello sprint, o conferma la configurazione del report automatico
Conferma la data del prossimo planning

Cosa trascura la maggior parte dei modelli di sprint planning

I modelli di sprint planning più diffusi si concentrano sul grooming del backlog e sulla definition-of-done. Entrambi sono importanti. Nessuno dei due affronta l'errore di pianificazione che produce il maggior numero di fallimenti di sprint: selezionare il lavoro senza verificare la disponibilità.

Un team di cinque ingegneri a piena capacità ha all'incirca 200 story point disponibili per sprint di 2 settimane. Un team di cinque con due ingegneri in ferie, uno a rotazione on-call e uno a un offsite di tre giorni ne ha forse 110. Se nel secondo sprint selezioni 180 punti, hai già fallito. Lo step di selezione è dove avviene l'over-commitment, e la capacità deve precederlo.

La seconda lacuna sono i criteri di accettazione. I team procedono spediti nel planning e intendono scrivere i criteri dopo. Il «dopo» non avviene con lo stesso livello di specificità. La persona che avrebbe scritto un criterio preciso in sede di riunione scrive qualcosa di più vago a memoria il giorno dopo, oppure non lo scrive affatto. I disaccordi a metà sprint su cosa significhi «concluso» sono quasi sempre riconducibili a criteri di accettazione saltati in fase di planning.

Il costo accumulato di queste lacune — sprint sovraccarichi, scoperte a metà sprint, definizioni rimesse in discussione — emerge chiaramente quando lo sommi: La tassa delle riunioni.

Perché le note dello sprint planning sono più difficili di quanto sembrino

Lo sprint planning genera più informazione di quasi ogni altra riunione ricorrente: l'obiettivo dello sprint, i numeri di capacità, la motivazione della selezione item per item, i criteri di accettazione per ogni ticket, i responsabili delle dipendenze, gli elementi di rischio. Scrivere un riepilogo utile richiede di catturare tutto questo in una forma che sia utile tre giorni dopo, quando qualcuno chiede «perché abbiamo tagliato quell'item?»

Pavleur genera automaticamente il report dello sprint planning alla fine della chiamata. Cattura l'obiettivo dello sprint, il backlog selezionato con la sua motivazione, i criteri di accettazione così come dichiarati durante la riunione e i responsabili delle dipendenze così come nominati. Se qualcuno ha condiviso a schermo il backlog o il foglio di calcolo della capacità, quell'elemento visivo è incluso nel report accanto alla discussione — un contesto che strumenti solo-audio come Otter o Fireflies trascurerebbero del tutto. Chiunque si sia unito in ritardo o abbia bisogno di verificare una decisione a metà sprint ha il resoconto completo. Per un confronto su come tutto questo differisca dagli strumenti solo-audio: Pavleur vs. alternative.

Gestire il cambio di piano a metà sprint

Il piano dello sprint è un impegno, non un contratto. Quando qualcosa a metà sprint invalida genuinamente il piano — un incidente in produzione, una dipendenza critica che blocca tre ticket, un cambio di priorità dalla leadership — la risposta giusta è una rapida chiamata di re-planning, non un abbandono silenzioso dello scope. La chiamata di re-planning richiede 20 minuti e produce un obiettivo dello sprint aggiornato che rispecchia la realtà. L'alternativa è uno sprint che fallisce sulla carta ma che viene aggiustato informalmente in modi che nessuno ha messo per iscritto, rendendo la retrospettiva più difficile e i numeri di velocity privi di significato.

Costruisci l'abitudine del re-planning esplicito. Usa la stessa struttura: capacità aggiornata, selezione rivista, obiettivo ri-dichiarato. Richiede molto meno tempo della confusione che previene.