Nella tua esperienza, quanto dovrebbe durare una riunione di Sprint Planning (Scrum)? 8 ore? O dovrebbe essere più breve (succinto) e ulteriori discussioni dovrebbero essere pianificate come parte dello sprint? I nostri Sprint durano 10 giorni.
In base alla Guida di Scrum :
The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings.
In genere funziona per me.
Finché deve durare, né meno né più. Qualcos'altro non è Agile.
Se hai un team di 2 - 3 sviluppatori e stai facendo scatti di 1 settimana, niente più di un'ora è controproducente.
Se hai una squadra di 15 persone e 2 settimane di sprint che guardi tutto il giorno, niente di meno non è abbastanza dettagliato.
Ci vuole esperienza per farlo in modo corretto, ed è a questo che 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 tratta di perfezionare il processo nelle iterazioni tanto quanto lo è nel perfezionamento del codice nelle iterazioni.
Non plasmare il tuo business in tutto il processo. Il processo supporta la tua attività. Nel momento in cui stai facendo un processo fine a se stesso è tempo che il processo ottenga l'ascia. A tal fine, non esiste un modo "giusto". Le riunioni dovrebbero andare solo finché si realizza qualcosa in esse. Se ti bastano 30 minuti o 4 ore, finché funziona, vai con esso. Ignora ciò che alcuni libri / blog / allenatore ti dicono e fai ciò che è giusto per te.
Prenditi tutto il tempo necessario per selezionare abbastanza che la tua squadra pensa di poter ottenere ragionevolmente nello sprint. Ma dovresti passare del tempo durante lo sprint (precedente) a perfezionare il backlog: stimare e perfezionare le storie.
Da Scrum Primer ( PDF ):
Product Backlog Refinement
One of the lesser known, but valuable, guidelines in Scrum is that five or ten percent of each Sprint must be dedicated by the Team to refining (or “grooming”) the Product Backlog. This includes detailed requirements analysis, splitting large items into smaller ones, estimation of new items, and re-estimation of existing items. Scrum is silent on how this work is done, but a frequently used technique is a focused workshop near the end of the Sprint, so that the Team and Product Owner can dedicate themselves to this work without interruption. For a two-week Sprint, five percent of the duration implies that each Sprint there is a half-day Product Backlog Refinement workshop. This refinement activity is not for items selected for the current Sprint; it is for items for the future, most likely in the next one or two Sprints. With this practice, Sprint Planning becomes relatively simple because the Product Owner and Scrum Team start the planning with a clear, well-analyzed and carefully estimated set of items. A sign that this refinement workshop is not being done (or not being done well) is that Sprint Planning involves significant questions, discovery, or confusion and feels incomplete; planning work then often spills over into the Sprint itself, which is typically not desirable.
Questo significa che puoi concentrarti sulla pianificazione durante la pianificazione, e non ci vuole tutto il giorno e il team inizia a perdere la concentrazione e si annoia.
In Scrum, quando si lavora per 2 settimane di sprint, la pianificazione dello sprint è time-boxed a 4 ore, rendendo un evento di mezza giornata. Una ragione per la quantità relativamente lunga di tempo è che il team di sviluppo deve essere in grado di accettare con sicurezza che tutti gli articoli inseriti nello sprint backlog possono essere consegnati, il che significa che devono conoscere i dettagli. Non è raro fare parte della pianificazione dello sprint per i team che si allontanano dallo spazio della riunione per periodi di tempo per indagare ulteriormente sugli elementi e assicurarsi che siano "pronti" per entrare nel backlog dello sprint. (Può essere utile pensare alla pianificazione dello sprint come a un evento, piuttosto che a un incontro.)
Usa la tua "Definizione di pronto" e il tempo che l'evento di pianificazione dello sprint consente di garantire che tutti gli elementi del backlog che entrano nello sprint siano fattibili e pronti . Ad esempio, possono essere completati (completamente, come da "Definizione di Fatto") all'interno dello sprint, e ci sono abbastanza informazioni per permettere al team di essere in grado di farlo proprio ora.
Si noti che probabilmente non si desidera eseguire questa operazione per TUTTI gli articoli durante la pianificazione dello sprint, poiché può richiedere molto tempo. Prova ad avere un regolare grooming del backlog (outwith sprint planning) in cui puoi suddividere gli elementi del backlog e stimare gli elementi non ancora stimati utilizzando il poker di pianificazione, ad esempio. (Ho scoperto che questa può essere un'attività efficace per una cena di lavoro con il team di sviluppo, se dovessi avere 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 solo prima della pianificazione sprint, e mentre il grooming del backlog di routine può, e normalmente dovrebbe essere fatto prima dell'evento di pianificazione sprint, ci saranno sempre nuovi elementi in questo modo il team deve dedicare del tempo a elaborare i dettagli e stimare la complessità durante l'evento di pianificazione sprint, quindi perché può allungare fino a 4 ore per sprint di 10 giorni / 2 settimane.
Se devi prendere discussioni più lunghe da questo evento, potresti avere un backlog nel backlog dello sprint per "avere una tale discussione per stabilire x", ma dovresti evitare di includere gli sprint per fare tutto ciò che vuoi stanno andando a determinare i bisogni fatti durante quella discussione, in quanto questi non sono elementi di backlog "pronti" per andare nello sprint.
Come hanno detto le persone, ci sono dei motivi 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 iniziare, quindi mi assicurerò che il tuo ragionamento sia giustificato prima di cambiare il processo.
Nello Sprint Planning Meeting, il team deve determinare due serie di cose:
A) Cosa verrà sviluppato dal team durante questo Sprint
B) Come sarà sviluppato
Questa riunione deve essere prenotata in orario, fino a due ore per ogni settimana dello Sprint, suddivisa 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à di squadra che ritengono di avere durante questo Sprint. Devono anche stimare le storie utente con priorità assoluta e scegliere abbastanza di queste storie utente (già stimate) da completare in linea con la loro velocità stimata del team.
Nella parte B, il team di sviluppo discuterà su come sviluppare le storie utente più difficili già selezionate da sviluppare. Molto probabilmente, il team di sviluppo non avrà abbastanza tempo per discutere su come sviluppare tutte le storie utente selezionate, quindi il team deve scegliere le storie utente più complesse.
Durante lo Sprint, il team di sviluppo ha tempo sufficiente per completare questa discussione.
In base alla Guida di Scrum :
Scrum Events
Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.