Quanto dovrebbe durare una riunione di pianificazione dello sprint?

Nella tua esperienza, quanto dovrebbe durare una riunione Sprint Planning (Scrum)? 8 ore? O dovrebbe essere più breve (breve) e ulteriori discussioni dovrebbero essere pianificate come parte dello sprint? I nostri Sprint durano 10 giorni.

Secondo la Scrum Guide :

Lo Sprint Planning Meeting ha una durata di otto ore per uno Sprint di un mese. Per Sprint più brevi, l'evento è proporzionalmente più breve. Ad esempio, gli Sprint di due settimane hanno riunioni di pianificazione Sprint di quattro ore.

Questo generalmente funziona per me.

Finché deve durare, niente di meno e niente di più. Nient'altro non è agile.

Se hai un team di 2-3 sviluppatori e stai facendo sprint di 1 settimana, qualcosa di più di un'ora è probabilmente controproducente.

Se hai una squadra di 15 persone e sprint di 2 settimane che stai guardando tutto il giorno, niente di meno non è abbastanza dettagliato.

Ci vuole esperienza per farlo nel modo giusto, ed è quello a cui servono le retrospettive, il team decide cosa è troppo lungo o troppo corto.

Non preoccuparti di renderlo perfetto o attenersi a ciò che dice un libro, provare qualcosa e perfezionarlo.

SCRUM riguarda il perfezionamento del processo nelle iterazioni tanto quanto il perfezionamento del codice nelle iterazioni.

Non plasmare la tua attività attorno al processo. Il processo supporta la tua azienda. Nel momento in cui stai eseguendo il processo per se stesso, è tempo che il processo ottenga l'ascia. A tal fine, non esiste un modo "giusto". Le riunioni dovrebbero durare solo finché si sta realizzando qualcosa al loro interno. Se impieghi 30 minuti o 4 ore, purché funzioni, procedi con esso. Ignora ciò che ti dice un libro / blog / coach e fai ciò che è giusto per te.

Prendi tutto il tempo necessario in modo da selezionare abbastanza da far sì che la tua squadra pensi di poter ragionevolmente raggiungere lo sprint. Ma dovresti passare del tempo durante lo sprint (precedente) a perfezionare l'arretrato: stimare e perfezionare le storie.

Da Scrum Primer ( PDF ):

Affinamento del portafoglio ordini

Una delle linee guida meno conosciute, ma preziose, in Scrum è che il cinque o il dieci percento di ogni Sprint deve essere dedicato dal Team a perfezionare (o "curare") il Product Backlog. Ciò include un'analisi dettagliata dei requisiti, la suddivisione di articoli di grandi dimensioni in elementi più piccoli, la stima di nuovi articoli e la rivalutazione di articoli esistenti. Scrum tace sul modo in cui questo lavoro viene svolto, ma una tecnica di uso frequente è un'officina focalizzata verso la fine dello Sprint, in modo che il Team e il Product Owner possano dedicarsi a questo lavoro senza interruzioni. Per uno Sprint di due settimane, il cinque percento della durata implica che per ogni Sprint ci sia un seminario di perfezionamento del Product Backlog di mezza giornata. Questa attività di perfezionamento non è per gli articoli selezionati per lo Sprint corrente; è per gli articoli per il futuro, molto probabilmente nel prossimo uno o due Sprint. Con questa pratica, Sprint Planning diventa relativamente semplice perché il Product Owner e lo Scrum Team iniziano la pianificazione con una serie di articoli chiari, ben analizzati e attentamente stimati. Un segno che questo seminario di perfezionamento non viene svolto (o non svolto bene) è che Sprint Planning comporta domande significative, scoperte o confusione e si sente incompleto; il lavoro di pianificazione spesso si riversa nello Sprint stesso, che in genere non è desiderabile.

In questo modo puoi concentrarti sulla pianificazione durante la pianificazione e non ci vuole tutto il giorno e il team inizia a perdere la concentrazione e ad annoiarsi.

In Scrum, quando si lavora per gli sprint di 2 settimane, la pianificazione dello sprint è programmata in 4 ore, rendendolo un evento di mezza giornata. Uno dei motivi della quantità relativamente grande di tempo è che il team di sviluppo deve essere in grado di concordare con fiducia che tutti gli elementi che vengono inseriti nel backlog dello sprint possono essere consegnati, il che significa che devono conoscere i dettagli. Non è insolito come parte della pianificazione dello sprint che i team si staccino dallo spazio della riunione per periodi di tempo al fine di indagare ulteriormente sugli elementi e assicurarsi che siano "Pronti" per entrare nel backlog dello sprint. (Può aiutare a pensare alla pianificazione dello sprint come a un evento, piuttosto che a una riunione.)

Utilizzare la "Definizione di pronto" e il periodo di tempo in cui l'evento di pianificazione dello sprint consente di garantire che tutti gli elementi arretrati che entrano nello sprint siano fattibili e pronti . cioè possono essere fatti (completamente, come da "Definizione del Fatto") all'interno dello sprint, e ci sono abbastanza informazioni per consentire al team di essere in grado di farlo in questo momento.
Nota che probabilmente non vorrai farlo per TUTTI gli articoli durante la pianificazione dello sprint, poiché può richiedere molto tempo. Prova ad avere un regolare backlog grooming (al di fuori della pianificazione dello sprint) in cui puoi scomporre gli elementi del backlog e stimare gli elementi non ancora stimati utilizzando, ad esempio, il poker di pianificazione. (Ho scoperto che questa può essere un'attività efficace per una cena di lavoro con il team di sviluppo, se hai il lusso della disponibilità del tuo team all'ora di cena!)

Gli articoli ad alta priorità possono spesso essere aggiunti al backlog del prodotto dal proprietario del prodotto appena prima della pianificazione dello sprint, e mentre la pulizia ordinaria del backlog può, e normalmente dovrebbe essere fatta prima dell'evento di pianificazione dello sprint, ci saranno sempre nuovi articoli come questo in cui il team deve dedicare tempo a elaborare i dettagli e stimare la complessità durante l'evento di pianificazione dello sprint, quindi perché può allungarsi a 4 ore per gli sprint di 10 giorni / 2 settimane.

Se è necessario eliminare discussioni più lunghe da questo evento, è possibile che nel backlog dello sprint sia presente un elemento di backlog per "tenere una discussione di questo tipo e tale da stabilire x", ma si dovrebbe evitare di includere gli elementi di sprint per fare tutto ciò che si intende determinare i bisogni fatti durante quella discussione, poiché quelli non sono elementi arretrati "pronti" per andare allo sprint.

Come hanno detto le persone, ci sono ragioni per cui potresti voler cambiare il modo in cui esegui Scrum se il processo non funziona in modo efficace per te. Scrum è comunque un framework molto ben pensato e testato per cominciare, quindi mi assicurerei che il tuo ragionamento sia giustificato prima di cambiare il processo.

Nella Sprint Planning Meeting, il team deve determinare due serie di cose:

A) Cosa sarà sviluppato dal team durante questo Sprint

B) Come sarà sviluppato

Questa riunione deve essere time-box, fino a due ore per ogni settimana dello Sprint, divisa equamente per ogni parte (parte A e parte B) della riunione.

Quindi, per uno Sprint di 4 settimane, questo incontro non dovrebbe durare più di 8 ore, fino a 4 ore per la parte A e fino a 4 ore per la parte B.

Durante la parte A, il team di sviluppo deve stimare la velocità del team che ritiene di avere durante questo Sprint. Devono anche stimare le storie degli utenti con la massima priorità e scegliere abbastanza di queste storie degli utenti (già stimate) per completare in linea con la velocità della squadra stimata.

Nella parte B, il team di sviluppo discuterà su come sviluppare le storie utente più impegnative già selezionate per essere sviluppate. Molto probabilmente, il team di sviluppo non avrà abbastanza tempo per discutere su come sviluppare tutte le user story selezionate, quindi il team deve scegliere le user story più impegnative.

Durante lo Sprint, il team di sviluppo ha abbastanza tempo per completare questa discussione.

Secondo la Scrum Guide :

Scrum Events

Gli eventi prescritti vengono utilizzati in Scrum per creare regolarità e ridurre al minimo la necessità di riunioni non definite in Scrum. Tutti gli eventi sono eventi temporizzati, in modo tale che ogni evento abbia una durata massima. Quando inizia uno Sprint, la sua durata è fissa e non può essere accorciata o allungata. Gli eventi rimanenti possono terminare ogni volta che viene raggiunto lo scopo dell'evento, garantendo un adeguato periodo di tempo senza consentire sprechi nel processo.