Guida Scrum · Eventi Scrum
Sprint Planning in Scrum: agenda, time-box e consigli
Lo Sprint Planning avvia lo Sprint definendo il lavoro da svolgere. L'intero Scrum Team collabora per creare un piano che tutti comprendono e in cui tutti credono.
Punti chiave
- Lo Sprint Planning risponde a perché, che cosa e come.
- Produce uno Sprint Goal e uno Sprint Backlog.
- Un backlog ben affinato rende rapida la pianificazione.
Time-box
Lo Sprint Planning ha un time-box massimo di otto ore per uno Sprint di un mese. Per Sprint di due settimane, molti team hanno bisogno di due-quattro ore, spesso meno quando il backlog è ben affinato.
Input
- Un Product Backlog affinato e ordinato.
- L'ultimo Increment.
- La capacità prevista del team.
- Le performance passate, come la velocity.
- La Definition of Done.
I tre temi
| Tema | Domanda | Risultato |
|---|---|---|
| Perché | Perché questo Sprint ha valore? | Uno Sprint Goal |
| Che cosa | Che cosa si può completare in questo Sprint? | Elementi del Product Backlog selezionati |
| Come | Come verrà svolto il lavoro scelto? | Un piano, spesso con elementi suddivisi in attività di un giorno o meno |
Lo Sprint Goal, gli elementi selezionati e il piano formano insieme lo Sprint Backlog.
Agenda di esempio (Sprint di due settimane)
- Rivedere il Product Goal e il contesto (10 minuti).
- Il Product Owner propone come lo Sprint potrebbe aumentare il valore (10 minuti).
- Il team concorda una bozza di Sprint Goal (15 minuti).
- I Developer selezionano gli elementi in base alla capacità (da 30 a 45 minuti).
- I Developer pianificano come svolgere il lavoro (da 45 a 60 minuti).
- Confermare lo Sprint Goal e l'impegno (10 minuti).
Errori comuni
- Elementi del backlog non affinati che richiedono ore di discussione.
- Uno Sprint Goal che è solo un elenco di elementi.
- Pianificare al 100% della capacità senza alcun margine.
- Il Product Owner o i manager che decidono quanto lavoro devono assumersi i Developer.
- Saltare il "come", così i problemi emergono a metà Sprint.
Modelli gratuiti per questo argomento
Domande frequenti
Chi partecipa allo Sprint Planning?
L'intero Scrum Team. Altre persone possono essere invitate a fornire consulenza.
Chi decide quanto lavoro entra in uno Sprint durante lo Sprint Planning?
Sono i Developer a decidere quanto lavoro possono assumersi, in discussione con il Product Owner.
Quanto dura lo Sprint Planning?
La Guida Scrum gli assegna un time-box massimo di otto ore per uno Sprint di un mese. Per Sprint più brevi l'evento è di solito più breve.
Quali sono i tre temi dello Sprint Planning?
Perché questo Sprint ha valore, che cosa si può completare in questo Sprint e come verrà svolto il lavoro scelto.
Qual è l'output dello Sprint Planning?
Uno Sprint Goal, gli elementi del Product Backlog selezionati per lo Sprint e un piano per consegnarli. Insieme formano lo Sprint Backlog.
Chi crea lo Sprint Goal nello Sprint Planning?
L'intero Scrum Team collabora per definirlo. Lo Sprint Goal deve essere finalizzato prima della fine dello Sprint Planning.
Come si calcola la capacità del team per lo Sprint Planning?
Partite dai giorni lavorativi disponibili per persona, sottraete ferie, riunioni e altri impegni e confrontate il risultato con le performance passate, come la velocity o il throughput.
Che cosa dovrebbe essere pronto prima dello Sprint Planning?
Un Product Backlog affinato e ordinato, l'ultimo Increment, la capacità nota, i dati sulle performance passate e la Definition of Done.
Le attività vanno stimate in ore durante lo Sprint Planning?
Scrum non lo richiede. Molti team suddividono gli elementi in attività di un giorno o meno invece di stimare le ore, il che fornisce dettagli sufficienti per monitorare l'avanzamento ogni giorno.
Gli stakeholder possono partecipare allo Sprint Planning?
Lo Scrum Team può invitare altre persone a fornire consulenza, ma le decisioni di pianificazione restano allo Scrum Team.
Che cosa fare se il team non riesce a concordare uno Sprint Goal durante lo Sprint Planning?
Esaminate la parte alta del Product Backlog alla ricerca di un obiettivo coerente, rivedete il Product Goal e chiedete al Product Owner quale risultato conta di più. Una difficoltà persistente segnala spesso un backlog di elementi scollegati tra loro.