Ho impiegato più di 5 ore nella pianificazione dello sprint per uno sprint di una settimana. Sembra troppo.

Discutiamo le cose in dettaglio nella pianificazione dello sprint, poiché la maggior parte dei membri del team non è senior. In caso contrario, si verificheranno errori durante l'implementazione e riprogettazione durante lo sprint.

Come gestiamo questo?

Di quanti dettagli dovrei discutere durante la pianificazione per adattarlo a una durata di 2 ore alla settimana?

Hai ragione: 5 ore in Sprint Planning per 1 settimana Sprint sembrano molto tempo. La Scrum Time-time Sprint Planning pianifica per 8 ore per 1 mese Sprint e afferma che "per Sprint più brevi, l'evento è generalmente più breve". Se si considera il rapporto, un buon obiettivo potrebbe essere 2 ore di pianificazione dello sprint per uno sprint di 1 settimana, ma non esiste un intervallo di tempo fisso.

Quindi, come si può affrontare una lunga pianificazione Sprint?

Come Scrum Master, vorrei seguire questi passaggi:

In primo luogo, collaborerei con il Product Owner per assicurarmi che il Product Backlog sia correttamente ordinato. È essenziale un efficace Backlog Refinement e Sprint Planning per assicurarsi che il lavoro più importante e le loro dipendenze siano in cima al Product Backlog in modo che lo Scrum Team possa concentrare le proprie energie sulla definizione, il perfezionamento e la preparazione del lavoro giusto.

In secondo luogo, mi assicurerei che il team stia dedicando abbastanza tempo al perfezionamento degli arretrati. La Scrum Guide indica che le attività di perfezionamento in genere non superano il 10% della capacità di un team di sviluppo. Ad esempio, un team di sviluppo di 4 persone che lavora una settimana standard di 40 ore dovrebbe pianificare circa 16 ore di perfezionamento del backlog. Questo può essere fatto individualmente, in piccoli gruppi o in gruppo. Ho scoperto che avere una sessione di perfezionamento degli arretrati pianificata per il team e poi esplodere per fare qualsiasi ricerca o indagine o pianificazione tende a funzionare al meglio.

Terzo, assicurati che il team si renda conto di non aver bisogno di ottenere tutti i dettagli giusti in Sprint Planning. L'obiettivo di Sprint Planning è produrre un piano per il completamento degli obiettivi Sprint. Non provare a progettare in grande stile in una sessione Sprint Planning. Comprendi come si adattano lavori diversi, dipendenze e obiettivi e usa il tempo al di fuori delle sessioni di Sprint Planning con le persone giuste per fare la progettazione, l'implementazione e i test necessari per consegnare il lavoro.

Potrebbero derivarne più passaggi, ma questo sarebbe un buon punto di partenza.

Ti sento. È troppo lungo da spendere! Speriamo che il tuo team ne discuta nelle tue retrospettive. Abbiamo provato diversi esperimenti con risultati contrastanti:

1. Ognuno fa un progetto di alto livello su un singolo biglietto e lo passa a sinistra o a destra attorno al tavolo per la revisione seguito da una revisione di gruppo del piano per ciascun biglietto. Non è piaciuto a tutti, ma ha costretto i nostri ragazzi a provarlo. Alcuni membri delle squadre sono abbastanza contenti di lasciare che altri pensino e seguono semplicemente le istruzioni. Quindi, per quanto riguarda il lato positivo, il nostro esperimento ha costretto tutti a confrontarsi con le loro lacune di conoscenza, fornendo una sfida alla crescita per i giovani. Sul lato negativo, non a tutti piace essere messi sul posto e non riduce necessariamente i tempi della riunione. Il prossimo!

2. Sono stati tentati progetti associati. Gruppi di due o tre avrebbero suddiviso un ticket in attività. L'intero team esaminerebbe i piani risultanti. Andò molto più veloce, ma alcuni mini-pod avevano lo stesso problema di una persona che cavalcava mentre l'altra faceva il lavoro sul design.

3. Salta la suddivisione dell'attività. Abbiamo deciso che i nostri punti della storia erano in media, quindi stavamo solo perdendo tempo cercando di coinvolgere tutto il team in tutto. Di conseguenza, abbiamo avuto riunioni di pianificazione molto più brevi, ma il lavoro di progettazione è stato qualcosa che le nostre coppie hanno dovuto fare da sole quando hanno iniziato un biglietto. Se i giovani stanno lavorando a un biglietto, aspettati che avranno bisogno di aiuto per superare questo passaggio. Se provi questo, accetta meno storie nello sprint fino a quando non ti senti a tuo agio. Inoltre, assicurati che sia "sicuro" per i tuoi compagni di squadra chiedere aiuto quando non sanno qualcosa.

Alla fine, si riduce alla maturità della squadra. Le persone devono comprendere le capacità e le preferenze reciproche e avere la certezza che i compagni di squadra chiederanno input quando ne avranno bisogno. Risolvili prima, se non li hai. Quindi risolvere il problema di riunioni inefficienti diventa più facile.

Mi piace la risposta che hai ricevuto da @ Thomas-Owens ma aggiungerò anche un altro elemento. Hai preso in considerazione la possibilità di programmare la coppia come parte della tua implementazione Agile?

La programmazione in coppia ti aiuterebbe con (1) insegnare ad alcuni dei tuoi programmatori junior come scrivere codice migliore e (2) nella programmazione in coppia, non devi sempre avere tutte le caratteristiche di progettazione progettate per te nella pianificazione dello sprint. Con la coppia che lavora insieme, alcune di queste decisioni di progettazione possono essere prese "spontaneamente" con i vantaggi di programmazione della coppia aggiunta.

Se puoi aiutare i tuoi programmatori junior a imparare più velocemente e sai che gli elementi di design che non hai affrontato in Sprint Planning saranno decisi da due persone, non c'è motivo per cui non sarai in grado di ridurre il tempo che passi futura Sprint Planning

Non sono un appassionato di scrum e ho solo circa un anno di esperienza pratica. Quindi, quanto segue deve essere letto con un granello di sale.

Vedo diverse bandiere rosse in quello che scrivi:

5 ore di pianificazione dello sprint

È troppo lungo per uno sprint di una settimana.

L'obiettivo della pianificazione dello sprint è AFAIR a

• consentire al team di sapere quali sono le priorità attuali e
• sviluppare un piano di battaglia per il prossimo sprint.

Per fare questo in modo efficace, ogni parte deve capire il Product Backlog items.

Per capire il Product Backlog itemsbacklog deve essere in buona forma.

Nella fase di pianificazione concreta, Product Backlog itemsvengono trasformati in Sprint Backlog items.

Una possibile causa è che questi elementi non sono sufficientemente chiari / perfezionati.

Un'altra possibile causa è che gli articoli sono troppo complessi e lasciano spazio a troppe interpretazioni.

Discutere molto dettagliatamente nella pianificazione dello sprint

Come detto sopra, la fase di discussione sarà più breve, quando gli argomenti saranno più concreti.

D'altra parte: la pianificazione Sprint prevede comportamenti professionali da parte di tutti i partecipanti. Ciò include evitare discussioni sul ciclismo .

Forse le cose sono chiare, ma qualcuno inizia una discussione sul ciclismo .

Altro: evitare discussioni sui dettagli di implementazione . Sebbene ogni idea finisca nel codice ad un certo punto nel tempo, non è il punto della discussione sulla pianificazione dello sprint, se un array semplice farà il trucco o sarà meglio usare un elenco collegato.

Poiché la maggior parte dei membri del team non è senior

Nella mischia non c'è distinzione tra senior e junior . Entrambi sono solo sviluppatori. E questo è un buon punto di partenza, che ti aiuta a mantenere la discussione focalizzata su una soluzione praticabile sostenuta da argomenti migliori e non dalla busta paga.

Errori di implementazione e riprogettazione durante lo sprint

Sembra esserci un problema fondamentale nella raccolta dei requisiti, seguito da un arretrato di prodotti molto vago.

Come ho detto sopra: fintanto che Product Backlogè in buona forma, dovrebbe essere difficile perdere il punto.

Non riesco a immaginare una situazione come:

»Come utente voglio vedere una manciata di clienti!«

»Oh, non intendevi tutti i nostri 2 milioni di clienti?«

OTOH: Cosa significa riprogettare in questo contesto ? Se uno sviluppatore ha scelto un algoritmo con prestazioni lente , allora il prossimo obiettivo è chiaro: sceglierne uno con prestazioni migliori. Ma questa non è una "riprogettazione", questa è un'ottimizzazione.

Alle tue domande principali:

Come gestirlo?

È banale menzionarlo, ma lo faccio comunque: non dimenticare che hai a che fare con gli umani .

È molto difficile avere un gruppo di menti diverse, che sono in grado di condividere concetti comuni (come in Rashomon ). Per far fronte in modo efficace a ciò, utilizzare la massima ridondanza nella comunicazione possibile: ad es. Spiegare il contesto dell'oggetto in modo esteso, anche se tutti "dovessero" sapere cosa fare. Poni delle domande, se tutti ottengono quale sia l'argomento di un determinato oggetto.

Se stai giocando a pianificare il poker un buon indicatore, se la comprensione è abbastanza buona, è che le attività sono classificate come basse. Bassa significa bassa complessità significa facile da capire e difficile da perdere.

Un effetto collaterale dell'iterazione è che i numeri per determinati compiti aumenteranno (perché il team ha una comprensione delle sue capacità e delle complessità nascoste). Quindi c'è la possibilità di scomporre l'oggetto in diversi oggetti meno complessi con una complessità inferiore.

Di quanti dettagli dovrei discutere durante la pianificazione per adattarmi allo sprint di 2 ore alla settimana?

Risposta salomonica: il meno possibile e il più necessario, ma non di più.

tl; dr

• Scegli una lingua semplice (se aiuta, usa un inglese semplice o ELI5) per evitare incomprensioni

• Migliora la raccolta dei requisiti

• Migliora il backlog

• Aumentare la fiducia dei membri del team nelle loro capacità individuali e nelle loro capacità di squadra

• Evita il ciclismo

• Migliora la disciplina personale

• Forse utilizzare intervalli temporali fissi per ogni oggetto da discutere

• Rafforzare la posizione del scrum mastermoderato in modo efficace.

Siamo riusciti a ridurre molto i tempi di pianificazione pianificando facendo un totale di tre ore in sprint di 2 settimane. Dividiamo la toelettatura in quattro sessioni. facciamo 30 minuti di toelettatura il lunedì e 1 ora di toelettatura il mercoledì ogni settimana. I nostri sprint iniziano il lunedì e terminano il venerdì. Di conseguenza abbiamo buone informazioni dalle riunioni di preparazione che contribuiscono come input alla pianificazione che lo rende più breve. Il nostro miglior record è stato un incontro di pianificazione della durata di 30 minuti in uno dei nostri sprint. Il più delle volte non ci vuole più di un'ora a un'ora e 30 minuti. È ancora tempo inscatolato comunque, ma la pianificazione è stata fatta molto presto.