Ho impiegato più di 5 ore in sprint planning 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. Se non lo facciamo, ciò porterà a errori durante l'implementazione e alla riprogettazione durante lo sprint.
Come ci occupiamo di questo?
Di quanti dettagli dovrei discutere durante la pianificazione per adattarlo a solo 2 ore di durata per uno sprint settimanale?
Hai ragione - 5 ore in Sprint Planning per uno Sprint di 1 settimana sembra un periodo lungo. Gli orari di Scrum Guide Sprint Pianifica fino a 8 ore per Sprints a 1 mese e dice che "per gli Sprint più brevi, l'evento è solitamente più breve". Se consideri il rapporto, un buon target può essere di 2 ore di Sprint Planning per uno Sprint di 1 settimana, ma non esiste un timebox fisso.
Quindi, come puoi affrontare una lunga Sprint Planning?
Come Scrum Master, vorrei seguire questi passaggi:
Innanzitutto, collaborerò con il Product Owner per assicurarmi che il Product Backlog sia ordinato correttamente. È 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 così che lo Scrum Team possa concentrare le proprie energie sulla definizione, sulla raffinazione e sulla preparazione del lavoro giusto.
In secondo luogo, farei in modo che il team stia spendendo un tempo sufficiente per il perfezionamento del Backlog. La Guida Scrum indica che generalmente le attività di perfezionamento non richiedono più del 10% della capacità di un team di sviluppo. Ad esempio, un team di sviluppo di 4 persone che lavora in una settimana standard di 40 ore dovrebbe pianificare circa 16 ore di perfezionamento del backlog. Questo può essere fatto individualmente, in piccoli gruppi o come una squadra. Ho scoperto che avere una sessione di perfezionamento del backlog pianificato per il team e poi scoppiare per fare qualsiasi ricerca o ricerca o pianificazione tende a funzionare al meglio.
In terzo luogo, assicurati che il team si renda conto che non è necessario ottenere tutti i dettagli direttamente in Sprint Planning. L'obiettivo di Sprint Planning è di produrre un piano per il completamento degli Sprint Goals. Non provare a fare grandi progetti in anticipo in una sessione di Sprint Planning. Scopri come si adatta il lavoro diverso, le dipendenze e gli obiettivi e utilizza il tempo al di fuori delle sessioni di Sprint Planning con le persone giuste per eseguire la progettazione, l'implementazione e i test richiesti per consegnare il lavoro.
Potrebbero esserci altri passaggi, ma questo sarebbe un buon punto di partenza.
Ti sento. È troppo lungo da spendere! Spero che il vostro team stia discutendo di questo nelle vostre retrospettive. Abbiamo provato diversi esperimenti con risultati misti:
Ognuno esegue una progettazione di alto livello su un singolo ticket e lo passa a sinistra oa destra attorno alla tabella per la revisione, seguito da una revisione di gruppo del piano per ogni ticket. Non è piaciuto a tutti questo, ma ha costretto i nostri juniores a provarlo. Alcuni individui sui team sono abbastanza contenti che lasciano pensare agli altri e seguono semplicemente le istruzioni. Quindi, per quanto riguarda il lato positivo, il nostro esperimento ha costretto tutti a confrontarsi con le proprie lacune nella conoscenza, fornendo una sfida alla crescita per i giovani. Sul lato negativo, non tutti amano essere messi sul posto e non necessariamente riducono il tempo durante la riunione. Avanti!
Sono stati tentati disegni accoppiati. Gruppi di due o tre abbatterebbero un biglietto in compiti. L'intero team esaminerà i piani risultanti. È andato molto più veloce, ma alcuni mini-pod hanno avuto lo stesso problema di una persona mentre l'altro ha fatto il lavoro sul design.
Salta la ripartizione dell'attività. Abbiamo deciso di calcolare la media dei nostri punti storia, quindi abbiamo perso tempo a cercare di coinvolgere tutto il team in tutto. Abbiamo avuto riunioni di pianificazione molto più brevi di conseguenza, ma il lavoro di progettazione era qualcosa che le nostre coppie dovevano fare da sole quando hanno iniziato un biglietto. Se i junior stanno lavorando un ticket, aspettati che abbiano bisogno di aiuto per superare questo passaggio. Se lo provi, accetta meno storie nello sprint finché non ti senti a tuo agio. Inoltre, assicurati che sia "sicuro" per i tuoi compagni di squadra per chiedere aiuto quando non sanno qualcosa.
Alla fine, arriva alla maturità della squadra. Le persone devono comprendere le rispettive capacità e preferenze e avere fiducia che i compagni di squadra chiederanno input quando ne avranno bisogno. Risolvi quelli prima, se non li hai. Quindi risolvere il problema delle 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 di coppie potrebbe aiutare a (1) insegnare ad alcuni dei tuoi programmatori junior come scrivere codice migliore e (2) nella programmazione di coppie, non è sempre necessario disporre di ogni singola funzionalità di progettazione prevista nella pianificazione sprint. Con la coppia che lavora insieme, alcune di queste decisioni di progettazione possono essere prese "spontaneamente" con i vantaggi aggiuntivi della programmazione.
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 potresti ridurre il tempo spendi nella futura Sprint Planning
Non sono un appassionato di mischia e ho solo circa un anno di esperienza pratica. Quindi il seguente è da leggere con un pizzico di sale.
Vedo diverse bandiere rosse in quello che scrivi:
Questo è troppo lungo per uno sprint di una settimana.
L'obiettivo della pianificazione sprint è AFAIR per
Per fare ciò efficacemente, ogni parte deve capire il Product Backlog items .
Per comprendere il Product Backlog items il backlog deve essere in buona forma.
Nella fase di pianificazione concreta, Product Backlog items viene trasformato in Sprint Backlog items .
Una possibile causa è che questi elementi non sono sufficientemente chiari / raffinati.
Un'altra possibile causa è che gli oggetti sono troppo complessi e lasciano spazio a troppe interpretazioni.
Come detto sopra, la fase di discussione sarà più breve, quando gli elementi saranno più concreti.
D'altra parte: la pianificazione dello sprint si aspetta un comportamento professionale da ogni partecipante. Questo include evitare discussioni in biciclette da golf .
Forse le cose sono chiare, ma qualcuno avvia una discussione bikeshedding .
Altro: evita discussioni su dettagli di implementazione . Sebbene ogni idea finisca nel codice ad un certo punto nel tempo, non è il punto della pianificazione dello sprint a discuterne, se un semplice array farà il trucco, o sarà meglio usare un elenco collegato.
As most of team members are not senior
In 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 concentrata su una soluzione praticabile supportata dagli argomenti migliori e non dallo stipendio.
Sembra esserci un problema fondamentale nella raccolta dei requisiti, seguito da un arretrato del prodotto molto vago.
Come ho detto sopra: finché il Product Backlog è in una buona forma, dovrebbe essere difficile perdere il punto.
Non riesco a immaginare una situazione del tipo:
»Come utente voglio vedere una manciata di clienti!«
»Oh, non intendevi ogni dei nostri 2 milioni di clienti?«
OTOH: che cosa significa in questo contesto riprogettazione ? Se uno sviluppatore ha scelto un algoritmo di esecuzione slow , allora il prossimo obiettivo è chiaro: scegli uno più performante. Ma non è una "riprogettazione", questa è un'ottimizzazione.
Per le tue domande principali:
How to deal with this?
È 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 siano in grado di condividere concetti comuni (come in Rashomon ). Per gestire efficacemente questo, usa la ridondanza nella tua comunicazione il più possibile: ad es. spiegare il contesto dell'elemento esteso, anche se tutti "dovrebbero sapere" cosa fare. Fai domande, se tutti hanno l'argomento di un determinato articolo.
Se stai giocando a pianificare il poker , un buon indicatore, se la comprensione è abbastanza buona, è che le attività sono classificate come basse. Basso significa bassa complessità significa facile da capire e difficile da perdere.
Un effetto collaterale dell'iterazione è che i numeri di certe attività aumenteranno (perché il team ha una comprensione delle sue capacità e delle complessità nascoste). Poi c'è la possibilità di suddividere l'articolo in diversi articoli meno complessi con una complessità inferiore.
How much detail should I discuss during planning to fit 2 hours long per a week sprint?
Risposta salomonica: il meno possibile e quanto necessario, ma non di più.
tl; dr
Scegli una lingua facile (se ti aiuta, usa inglese semplice o ELI5 ) per evitare equivoci
Migliora la raccolta dei requisiti
Migliora il backlog
Aumenta la fiducia dei membri del team nelle loro capacità individuali e le loro capacità come squadra
Evita lo slittamento delle biciclette
Migliora la disciplina personale
Forse usa intervalli di tempo fissi per ogni elemento da discutere
Rafforza la posizione di scrum master per moderare in modo efficace.
Siamo riusciti a ridurre molto i tempi di riunione della pianificazione eseguendo un grooming di tre ore totali in scatti di 2 settimane. Dividiamo il grooming in quattro sessioni. facciamo 30 min grooming in lunedì e 1 ora grooming in mercoledì ogni settimana. I nostri scatti iniziano lunedì e termina venerdì. Di conseguenza, disponiamo di buone informazioni provenienti dagli incontri di toelettatura che contribuiscono come input alla pianificazione che lo rende più breve. Il nostro miglior record è stato un incontro di pianificazione 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. Comunque è ancora in tempo, ma la pianificazione è stata fatta molto presto.