Non solo le nostre riunioni di pianificazione dello sprint non sono divertenti, ma sono addirittura terribili.

Gli incontri sono noiosi, noiosi e durano per sempre (un giorno, ma sembra molto più lungo).
Gli sviluppatori si lamentano e temono le prossime pianificazioni.

La nostra routine è piuttosto standard (la storia dell'utente è stata inserita nel backlog dello sprint per priorità >> la storia è suddivisa in compiti >> le attività sono stimate in ore >> ripeti) e non riesco a capire cosa stiamo facendo di sbagliato.

Come possiamo rendere più piacevoli le riunioni?

...

Alcuni ulteriori dettagli, in risposta alle richieste di ulteriori informazioni:

Perché gli elementi del backlog non sono inseriti e hanno la priorità prima del calcio d'inizio dello sprint?

Le storie degli utenti sono davvero prioritarie; non abbiamo idea di quanto tempo impiegheranno prima di scomporli in compiti! Dalle risposte (eccellenti) qui, vedo che forse non dovremmo stimare affatto le attività, ma solo le storie degli utenti. Il motivo per cui stimiamo i compiti (e non le storie) è perché le stime delle storie sono state terribilmente sbagliate, ma immagino che sia l'oggetto di una domanda completamente diversa.

Perché gli sviluppatori si lamentano?

1. Le riunioni sono lunghe.

2. Gli incontri sono monotoni. Storia dopo storia, compito dopo compito, lotta (sì, lotta) per stimare quanto tempo ci vorrà e cosa comporta.

3. Stimare le attività fa sembrare inutile la stima della user story.

4. Più è lungo l'incontro, minore è il focus nella stanza. Più i colleghi sono meno concentrati, più tempo impiegherà la riunione. Si sviluppa una spirale dell'odio ricorsiva. Abbiamo preso in considerazione la possibilità di suddividere l'incontro in due giorni per mantenere le persone concentrate, ma gli sviluppatori non ne avrebbero sentito parlare. Un giorno di pianificazione è abbastanza brutto; ora ne avremo due ?!

Parte del nostro problema è che entriamo nei minimi dettagli (al fine di ottenere stime più accurate). Ma quando stimiamo approssimativamente, andiamo molto lontano!

Per riassumere la domanda:

• Cosa stiamo sbagliando?

• Quali altri modi ci sono per rendere la riunione generalmente più piacevole?

Rendi la stima più semplice

Abbatti la tua pianificazione dello sprint.

Hai bisogno di stimare i singoli compiti? Ho fatto lo sprint pianificando due modi:

1. Le storie sono stimate in punti della storia e quindi le attività sono stimate in ore
2. Le storie sono stimate nei punti della storia e le attività rientrano semplicemente in quelle senza stima

Dei due, preferisco la seconda opzione. Trovo che non stimare i compiti dia più libertà agli sviluppatori per far fronte ai cambiamenti. Se un'attività non ha più senso (quante volte hai scoperto che un'attività non è applicabile o era già stata eseguita in uno sprint precedente), semplicemente la butti fuori senza alcuna penalità o potresti dover cambiare un'attività corrente in qualcosa di nuovo, possibilmente distruggendolo. Sei davvero ridondante se stimhi entrambi, poiché la somma dei compiti dovrebbe rappresentare i punti della storia e viceversa. Quale valore guadagni davvero da questo oltre a sapere quanto tempo impiegheranno le singole attività? Se ti trovi con dimensioni di attività che variano davvero abbastanza da fare la differenza, suggerirei di suddividere tali attività in blocchi più piccoli e più omogenei.

In questo modo, puoi ridurre il tempo impiegato nella pianificazione dello sprint . Le storie vengono stimate durante la pianificazione dello sprint e quando inizi lo sprint puoi mettere a tacere tutti i compiti che riesci a pensare a quella storia. Ovviamente se ci sono dei punti che si incontrano nella stima della storia che si sa che dovrà essere affrontata in un'attività, è possibile aggiungerla alle informazioni della storia e inserirla come attività.

Stima in unità ideali

Punti di storia sono destinate ad essere in ideali di unità , come ore di lavoro ideale o giorni di lavoro ideali. Questi hanno lo scopo di significare che, dato il giorno perfetto ogni giorno, in cui non hai avuto interruzioni, riunioni, e tutto è andato secondo i piani, potresti compiere il compito in X giorni. Ora tutti sanno che questo semplicemente non è vero, ma la cosa meravigliosa delle statistiche è che non deve essere così.

Ciò che intendo con questo è che dopo un po 'di stima di questi in giorni ideali, ti rendi conto che forse ci vuole un 25% in più del tempo stimato in media per completare una storia. Supponiamo che tu abbia stimato 4 giorni di lavoro ideali, e invece ci sono voluti 5. Nel tempo, tieni traccia di questo e poi hai un'idea approssimativa della conversione da giorni ideali a giorni reali. Il tuo primo istinto sarebbe quello di cercare di compensare ciò stimando eccessivamente, e probabilmente sbaglieresti. La cosa principale qui è rimanere coerenti. In questo modo, la tua media a lungo termine rimane la stessa. Certo a volte, sarà sotto e a volte finirà, ma più si stima, meglio si è. Se lo trovi ancora non è possibile ottenere una stima decente, forse significa che non si conosce abbastanza della storia per stimarla correttamente.

Parla delle storie

Quando stimate, tutti dovrebbero avere un'idea approssimativa di ciò che dovrà essere fatto, dall'inizio alla fine, di ciò che ci vorrà affinché questa storia sia completa. Non è necessario conoscere ogni dettaglio, ma abbastanza da pensare che tu stesso possa intraprendere la storia. Se non hai quel livello di confidenza, probabilmente non dovresti stimarlo. Se dici "Beh, questa storia è troppo grande per noi per conoscere la maggior parte dei dettagli", ciò indica che la storia è troppo grande e dovrebbe essere scomposta. Le storie, almeno secondo la mia esperienza, sono state abbastanza piccole da consentire a una persona, se necessario, di lavorarci da solo e realizzarle entro una o due settimane.

Questo aiuterà anche a risolvere il tuo secondo punto nella modifica, che è troppa stima . Invece di stimare ogni singola attività per ogni singola storia, devi semplicemente stimare la storia nel suo insieme, il che dovrebbe aiutare a rimuovere molta della stima. Per quanto riguarda il rendere gli incontri meno monotoni, suggerirei di pianificare il poker, di cui puoi vedere maggiori informazioni sopra.

Rendi la pianificazione più coinvolgente

Stima utilizzando Planning Poker

Per quanto riguarda la stima più divertente, hai provato a pianificare il poker ? È il modo in cui ho sempre pianificato tutti i miei sprint su più squadre, ed è un buon modo per coinvolgere tutti, poiché ogni persona deve almeno scegliere QUALCOSA. C'è anche un bel po 'di divertimento quando tutti nella squadra scelgono 3, e qualcuno mette giù un 20 e deve spiegarsi, o quando tutti nella squadra mettono giù un 5 ma il manager ne abbatte un 8 (con chi litigherà il capo quando vuole darti più tempo!).

Per fare ciò, tutto ciò di cui hai bisogno sono alcune carte da poker di pianificazione , che spesso realizziamo sul retro delle carte indice o che utilizzano normali carte da gioco con valori associati alle carte faccia. Niente di speciale e mantiene tutti concentrati. Ricorda solo che provare a svolgere qualsiasi attività per un'intera giornata (compresa la pianificazione del poker) ha un impatto sulla produttività. Molti set di carte vengono forniti con una carta caffè per un motivo; se qualcuno si sente stremato, concedi alla squadra una pausa per ricaricarlo e raccogliilo quando tutti sono freschi!

In alternativa alle carte fisiche , puoi anche guardare le carte elettroniche . I vantaggi reali qui sono il tracciamento automatico dei risultati, il monitoraggio delle storie degli utenti da stimare e la possibilità per tutti di mostrare le proprie carte contemporaneamente per evitare "imbrogli" (laddove la stima di una persona è influenzata da un'altra perché è in grado di vedere la propria carta). Ovviamente ciò richiede che tutti abbiano un computer e la possibilità di concentrarsi sull'attività da svolgere, quindi utilizzalo a tua discrezione.

1. Perché gli elementi del backlog non sono inseriti e hanno la priorità prima del calcio d'inizio dello sprint? Sprecare tempo per gli sviluppatori non è divertente. Lascia che il tuo team conduca i lavori con il proprietario del prodotto e il project manager qualche giorno prima per dare priorità alle cose. Questo vale per pianificare anche chi fa parte di ogni squadra di sprint.

2. Perché ci vuole un giorno per dividere le cose in compiti? Se hai un team di dimensioni ragionevoli (2-4 sviluppatori, 0,5-1,5 persone con QA per sviluppatore, 1-2 misc), dovresti avere 2-4 storie utente in questo sprint. Trascorri circa 30 minuti con i requisiti di chiarimento del proprietario del prodotto, quindi circa 30 minuti suddividendoli in attività di circa 8 ore. Non inserire le attività durante la riunione. Basta concordare in gruppo quali compiti sono sufficienti affinché le persone sane li capiscano, chi ne sia responsabile e su quanto tempo dovrebbero impiegare. Concorda che "quanto tempo dovrebbero impiegare (compresi i test)" si adatta comodamente allo sprint.

3. Se non si tratta solo di spezzare le cose in compiti, cos'altro stai facendo? Certo, le retrospettive possono richiedere 30-60 minuti, ma saranno più brevi man mano che le squadre entrano in un ritmo.

Quindi, in sintesi, smetti di perdere tempo e temeranno gli incontri un po 'meno. Oltre a ciò, il divertimento e il compagno nella squadra non sono qualcosa che puoi affrontare nelle riunioni. Andare a pranzo insieme, scherzare, mescolare le persone per adattarsi meglio alla personalità, fare gare in crescita con i baffi ... una volta che il morale è salito, le persone renderanno naturalmente più veloci le riunioni di pianificazione dello sprint.

La pianificazione è un'area di mischia in cui i team hanno molta flessibilità. Prova qualcosa di nuovo ogni sprint fino a quando non colpisci qualcosa che funziona per la tua squadra.

Alcune idee di successo che ho provato personalmente o di cui ho sentito parlare da altri team:

• Crea la creazione e la definizione delle priorità della user story senza l'intero team. Il proprietario del prodotto e / o lo Scrum Master possono gestire gran parte del lavoro occupato e lasciare che il team lo modifichi.
• Rendi il tuo backlog significativamente più lungo di un singolo sprint. La costruzione può richiedere del tempo, ma se l'arretrato è abbastanza lungo, la pianificazione delle riunioni si riduce a fare piccole modifiche o affrontare i recenti sviluppi aziendali.
• Avere riunioni di stima separate dalla pianificazione dello sprint. Se le persone pensano che le riunioni siano troppo lunghe, non c'è motivo di non dividerle.
• In particolare, il piano rompe l'agenda. Questo è utile se stai spesso perdendo tempo ad aspettare che uno o due membri del team ritornino.
• Rompi nel mezzo della riunione e assegna a tutti di elaborare una o due storie utente, quindi riuniti per riferire e ottenere consenso.
• Assicurati che la tua riunione di pianificazione riguardi cosa fare, non come farlo. Gli ingegneri cadono molto facilmente in quest'ultimo. Se necessario, organizzare riunioni di progettazione separate in cui discutere del come.
• Separa le tue storie in indagini e implementazione. Le riunioni di pianificazione spesso durano troppo a lungo quando i membri del team sanno troppo poco su cosa lavoreranno e provano a capirlo durante l'incontro.
  Ad esempio, supponiamo che tu debba integrarti con un'API di cui il tuo team non ha esperienza. Invece di provare a creare stime e attività durante l'incontro di pianificazione su qualcosa di cui non hai idea, fai una storia di indagine per imparare l'API, fai una semplice app "ciao mondo" e insegnala al team. Quindi sarai attrezzato per pianificare il lavoro effettivo.
• Tieni traccia durante le tue riunioni di problemi specifici. Non solo "la pianificazione è noiosa", ma un livello di dettaglio come "passiamo molto tempo a parlare di requisiti poco chiari e nessuno sembra conoscere la risposta giusta". Quindi discuti di questi problemi specifici nelle tue retrospettive e fai brainstorming per soluzioni specifiche. Rompi il problema finché i pezzi non sono facili da risolvere.

Manteniamo la nostra pianificazione dello sprint e la retrospettiva allo stesso tempo e quasi sempre in 90 minuti, ma siamo una delle squadre più veloci. Facciamo una grande pianificazione a lungo termine a livello aziendale ogni 5 sprint che richiede 4-6 ore. Ogni squadra è diversa, ovviamente, ma se stai trascorrendo un'intera giornata ogni sprint, c'è molto margine di miglioramento.

Le tue sessioni di pianificazione sono troppo lunghe!

In base alla mia esperienza, una riunione di pianificazione dello sprint non dovrebbe richiedere più di 2 ore settimanali in programma (ad esempio, uno sprint di 2 settimane dovrebbe durare al massimo 1/2 giornata), ma quelli riusciti dovrebbero essere più brevi di quello (metà).

Nel tuo caso particolare: perché stai valutando le attività? Dovresti stimare solo le storie durante la pianificazione. Le attività possono essere stimate in seguito dai proprietari specifici delle attività .

Un modo che ha funzionato per me:

• Introduzione rapida allo sprint da parte dell'OP
• Stima della capacità di sprint
• Le storie si esauriscono e pianificano il poker (timebox a 5/10 minuti per storia) fino a quando non ci sono abbastanza cose stimate per coprire lo sprint
• Impegno / previsione ufficiale da parte del team

Quindi, in parallelo / coppie / auto-organizzati presso i nostri banchi, tasking e stima delle attività.

Nel mio lavoro precedente, l'intero primo giorno di ogni sprint (li abbiamo chiamati iterazioni lì) è stato ripreso con:

• Retrospettiva. Abbiamo iniziato a farlo nel pomeriggio dell'ultimo giorno, ma spesso ci siamo ritrovati a riflettere sullo sprint e poi a tornare a lavorare legando le ultime estremità libere del lavoro di quello sprint, quindi abbiamo pensato che sarebbe stato meglio assicurarsi che il lavoro era tutto alle nostre spalle prima di ripensarci. Sembrava inoltre logico consolidare tutto il meeting overhead del processo Scrum in modo che gli altri giorni potessero essere pianificati e spesi in termini più ideali. In genere sono state necessarie 2 ore.
• Sprint Planning. L'arretrato è stato stimato durante una riunione di pianificazione delle pietre miliari (che potrebbe essere un'intera giornata in sé sia ​​per gli sviluppatori che per gli ordini di acquisto), ed era stato dato priorità dalle OP prima dell'inizio di ogni sprint. Abbiamo capito quanti giorni di sviluppo avevamo a disposizione (contabilità per vacanze, vaca, ecc.), Abbiamo afferrato il lavoro che pensavamo di poter fare in cima alla pila e rapidamente rivisto i requisiti dell'utente (precedentemente controllati dai nostri BA) per avere un'idea più completa di ciò che il lavoro ha comportato rispetto a quanto abbiamo ottenuto con la semplice panoramica durante l'MPM. In genere ciò ha richiesto altre 2 ore.
• Pianificazione delle attività. Conoscendo le storie e i criteri di accettazione, abbiamo suddiviso ogni storia in compiti di dimensioni ridotte stimati in ore ideali (un'ora trascorsa concentrata esclusivamente sul portare a termine quel compito senza distrazioni o blocchi). Il modo in cui la nostra scala di punti ha finito per essere calibrato, un 5 era uno sprint per sviluppatori, quindi un 1 poteva essere qualsiasi cosa fino a due giorni di sviluppo inclusi. Per questa ragione, praticamente tutto doveva essere scomposto per consentire ai membri del team di mostrare i progressi sulla mischia. Questo è stato un altro blocco di 2 ore, con un po 'di dare-e-prendere tra questo e l'elemento successivo.
• Delineare AAT. I nostri PO e BA non erano programmatori e non programmavano. Le OP si nascondevano dietro un contratto che prevedeva che avrebbero fornito i requisiti sotto forma di un modello di Word e avrebbero collaborato con le BA per perfezionarle in quel modulo. Le BA capivano il codice, ma il loro tempo era puramente analisi e test finali (che richiedevano l'esistenza del sistema, in modo da poter registrare le loro macro nel selenio). Quindi, per verificare che il nostro codice avrebbe soddisfatto i criteri di accettazione quando si è arrivati ​​a questo, abbiamo dovuto scrivere le nostre AAT modellando le azioni del test di accettazione "cartaceo". In genere lo abbiamo fatto nello stesso framework NUnit che abbiamo usato per i test di unità e integrazione (abbiamo provato FitNesse e non abbiamo potuto rinunciare abbastanza velocemente). Questo è stato il resto del nostro primo giorno di ogni sprint ed è continuato nel secondo.

Nel mio attuale lavoro, stiamo ancora adottando il processo Scrum, non avevamo una pietra miliare a livello di team e gran parte di ciò a cui stiamo lavorando non ha rigidi criteri di accettazione. Quindi, la nostra pianificazione dello sprint è tanto una spiegazione di ciò che ogni storia comporta e di ciò che chiameremo fatto, quanto è un impegno a prendere le prime X ore ideali di lavoro dall'alto. Ce la caviamo - almeno per ora - perché siamo un team interno e ognuno di noi lavora personalmente con gli utenti finali del nostro software per raccogliere requisiti e soluzioni di progettazione. Anche in questo caso, la pianificazione dello sprint è una cosa che dura tutta la mattina ogni due lunedì e il pomeriggio viene speso eliminando tutti i blocchi personali per poter iniziare lo sviluppo martedì.

Per rispondere effettivamente alla domanda del PO piuttosto che contrastare altri commenti / risposte dicendo che non dovrebbe richiedere così tanto tempo, ci sono modi per avvicinarsi alla stima Agile, alla pianificazione dello sprint e alle retrospettive che sono un po 'più interessanti di quanto potresti usare.

Affrontare in modo specifico le tue preoccupazioni:

• Le riunioni sono lunghe - Time-box loro. Ogni incontro, che si tratti di una retrospettiva, di una pianificazione dello sprint, di una suddivisione dei compiti, ecc., Dovrebbe avere uno scopo e un argomento di discussione definiti e dovrebbe essere limitato il più possibile a un determinato periodo di tempo. È compito dello Scrum Master tenere queste riunioni sull'argomento e proseguire per raggiungere gli obiettivi di tempo.

• Le riunioni sono monotone - Ce ne saranno alcune; stai lavorando a pezzi di dimensioni ridotte, uno alla volta, quindi farai sempre la stessa cosa. Mantenere il team concentrato e guidare verso il raggiungimento dello scopo della riunione aiuterà.

  Qualcos'altro che sento è che forse le tue riunioni di pianificazione dello sprint stanno cercando di ottenere troppo. Nella mia ultima azienda, la stima della storia è stata fatta durante le "riunioni di pianificazione delle pietre miliari", avvenute circa una volta al trimestre e prese tutto il giorno. In quegli incontri, tutto ciò che si era accumulato nel backlog che non avevamo stimato era stimato in punti. Se stai facendo la stima della storia in punti e poi la stima dell'attività in ore, non vuoi farle entrambe allo stesso tempo (forse lo stesso giorno).

• Stimare storie in punti, poi le attività in ore sembra ridondante : hanno due scopi diversi. Lo scopo della stima della storia è di fornire una stima approssimativa della complessità, che è possibile utilizzare per riempire il backlog dello sprint in base alla velocità passata e alla larghezza di banda prevista. Lo scopo della stima delle attività è quello di scomporre le storie in cose che richiedono un giorno di sviluppo o meno (e quindi possono essere assegnate a un singolo ragazzo che dovrebbe avere tutto in tempo) e assicurarsi di non averlo stimare erroneamente la complessità di qualsiasi storia, né morso più di quanto si possa masticare nello sprint.

  Se le tue storie impiegano tutte un giorno o meno, allora sono ridondanti, ma non tutte le scale dei punti sono calibrate allo stesso modo; nel mio ultimo lavoro, un 5 era di due settimane di sviluppo (perché all'inizio avevamo molte epopee da stimare), che su una scala lineare faceva un punto qualsiasi fino a 2 giorni di sviluppo. Dato quel tipo di scala, praticamente tutto dovrebbe essere suddiviso in compiti. Nella mia nuova azienda, un punto è più vicino a mezza giornata di sviluppo, quindi un 1 o anche un 2 è sicuramente il suo compito, e 3-8 è nebuloso per quanto riguarda il forzare il team a dividerlo in attività.

• C'è un circolo vizioso che impiega più tempo a rendere le persone meno concentrate, quindi impiega più tempo - Time-box il tuo time-box. Fai delle pause, proprio come dovresti fare durante la programmazione. Ogni 30 minuti, impiega 5 minuti per allungare le gambe, riorganizzarti, ecc. Puoi farlo dieci minuti ogni ora, ma non spingere un blocco solido del tempo di riunione troppo oltre. I tuoi ragazzi potrebbero avere fame, o avere bisogno di più caffè, o una pausa bagno, ecc. Non negarli; se li fai succhiare, troverai le loro menti vaganti. Oltre a ciò, anche mantenere le discussioni brevi, dolci e mirate aiuterà, come già accennato.

La riunione di pianificazione di Sprint è suddivisa in 2 parti:

1. Decidi cosa farà la squadra
2. Decidi come lo farà il team.

La prima parte è relativamente semplice: in base al numero di punti della storia che il team sente di poter affrontare, l'impegno a completare tutte le storie degli utenti nel loro ordine di priorità. Fatto.

La seconda parte è ciò che gli sviluppatori dovrebbero effettivamente apprezzare: elaborazione della storia e progettazione della soluzione. I compiti non ne derivano. Quindi, fai in modo che il proprietario del prodotto, o qualunque altra PMI abbia fornito, spieghi una storia scelta. Quindi chiedi a qualsiasi sviluppatore di occuparsene, conduci la discussione di progettazione. Usa una lavagna bianca. Rimbalzare idee in giro. Divertiti.

Questo è tutto, davvero. Se le riunioni di progettazione non sono divertenti, allora c'è semplicemente qualcosa che non va.

Sì, so che questa è una vecchia domanda, ma ho una nuova risposta. : P

Dividi l'incontro.

Abbiamo diviso il nostro meeting di pianificazione Sprint in 3 mini-meeting separati

• Toelettatura degli arretrati
• Selezione della storia
• Ripartizione dell'attività

Facciamo ognuno in un giorno diverso, subito dopo la nostra Scrum quotidiana - non appena il quotidiano è finito, entriamo direttamente nell'attività di pianificazione e poi siamo liberi dalle riunioni (pianificate regolarmente) per il resto della giornata.

Quindi sì, abbiamo messo a repentaglio la nostra pianificazione: -O

Vado più in dettaglio su ciò che è coinvolto in ogni sessione in un secondo, ma lasciami spiegare come siamo arrivati ​​a questo.

Come te, abbiamo avuto problemi con riunioni di pianificazione Sprint davvero terribili. Avevamo tutti gli elementi giusti, ma tutto è durato per sempre ed è stato davvero faticoso mentalmente ed emotivamente per farcela.

Poi ho avuto questa idea dopo aver letto questo articolo di Business Insider sul quotidiano di 5 minuti di Pivotal sul dividere i nostri incontri in sessioni più brevi e farli all'inizio di ogni giornata.

L'ho portato con il team in una retrospettiva. Ad alcuni membri del team è piaciuta subito, altri erano un po 'preoccupati, ma poi il nostro stagista ha menzionato alcuni studi che ha letto sulla tecnica del pomodoro e ha iniziato a parlarne, e questo ha davvero aiutato l'idea di ottenere trazione.

Quindi abbiamo deciso di provarlo.
Abbiamo interrotto il nostro incontro di 2 ore in tre sessioni da 25 minuti. (sì, è una matematica confusa, ma tutti pensavano che i nostri incontri fossero troppo lunghi e volevano farlo solo se avessimo risparmiato tempo).

E ha funzionato! Lo facciamo da circa 6 settimane su due progetti separati (6 sprint di due settimane in totale) e ha fatto la differenza.
Siamo più produttivi. Risparmiamo un sacco di tempo.
Otteniamo risultati migliori. E non temiamo più le nostre riunioni di pianificazione.

E onestamente, il nostro intervallo di tempo di 25 minuti è piuttosto lento: alcune sessioni vanno molto velocemente, come 5-10 minuti in alcune delle nostre sessioni di toelettatura, e altre durano a lungo, come quando finiamo per identificare nuove storie o dover romperle e rivalutare durante la negoziazione. Complessivamente, in genere, in media non supera le 1,5 ore per l'intero shebang, e penso che sia per questo che funziona così bene.

Dai dettagli .....

Toelettatura degli arretrati

Abbastanza semplice: passiamo in rassegna le storie prioritarie, parliamo di ciò che esse comportano e ci assicuriamo che le nostre stime siano buone.

Se necessario, rivaluteremo le storie - come diciamo che abbiamo stimato qualcosa mesi fa e dopo aver realizzato ciò che una storia simile ha effettivamente preso, potremmo concordare di rivalutare. (ad ogni modo usiamo punti trama senza unità e non stimiamo le attività ).

Inoltre, se l'OP ha aggiunto nuove storie che ritiene prioritarie, questo è il momento di stimarle.

Poiché non eseguiamo la selezione della Storia fino al giorno successivo, questo processo dà all'OP un po 'di tempo in più per dare un giudizio finale su ciò che è più importante da fare nella prossima iterazione - e questo si è rivelato molto utile.

Questo incontro tende ad essere corto con alcuni PO e lungo con altri. (personalmente, penso che sia un ottimo indicatore di odore di come sta andando il tuo PO)

Selezione della storia

Accendi il tuo Chris Voss , è tempo di negoziare.

In questa riunione prendiamo le storie con la massima priorità e definiamo un DoD per ognuna. Negoziamo ciò che ciascuno comporterà - suddividere e combinare le storie secondo necessità - fino a quando non saremo tutti d'accordo sugli obiettivi di Sprint.

Beneficiamo molto di avere nuove menti e quell'energia del buongiorno per questo incontro - e sapere che faremo compiti un altro giorno ci consente di trascorrere il tempo necessario per negoziare davvero bene e comprendere i nostri impegni.

Compiti

Va bene, quindi sarò il primo a dirlo, i compiti erano la mia MINIMA parte preferita della pianificazione nei nostri vecchi incontri di un giorno.

Non ci siamo mai spinti a fare questo. Abbiamo provato a salvare i compiti fino alla fine della riunione, ma a quel punto eravamo tutti svuotati ed era davvero improduttivo. Durante la nostra negoziazione abbiamo provato a definire i compiti contemporaneamente al nostro DoD, ma lo abbiamo trovato troppo distratto e ingombrante: ci saremmo bruciati prima di selezionare tutte le storie. Inoltre, è stato davvero difficile continuare a cambiare focus / pensiero tra stima, negoziazione, selezione della storia e generazione di attività. Abbiamo faticato, e ha fatto schifo, e ha reso orribili le nostre riunioni.

Ma ora, definendo il Dipartimento della Difesa un giorno e non svolgendo compiti fino al giorno successivo, non ci esauriamo, siamo sempre nel giusto stato mentale e ci dà un'intera giornata per marinarci sulla storia e davvero riflettere e comprendere tutti i compiti prima di iniziare.

Solo questo, IMHO, è un punto di svolta.

Mettere tutto insieme.

Quindi, ecco come appare il nostro programma della cerimonia Sprint:

• Lunedì - Scrum giornaliero -> Recensione Sprint
• Martedì - Scrum giornaliero -> Backlog grooming
• Mercoledì - Scrum giornaliero -> Selezione della storia
• Giovedì - Scrum giornaliero -> Compiti
• Venerdì - Scrum giornaliero -> Retrospettiva

Ha funzionato davvero bene per noi. Se ci provi, mi piacerebbe sapere cosa ne pensi.

Stiamo effettuando uno sprint settimanale con un incontro di un'ora in cui discutiamo dello sprint precedente, cosa resta da fare e poi passiamo alla pianificazione della prossima settimana. Tutto entro un'ora.

Questo ovviamente perché abbiamo scoperto che nel nostro caso seguire la mischia troppo strettamente perderebbe solo troppo tempo. Questo perché la maggior parte delle storie sono già state discusse con i membri del nostro team quando il richiedente crea la user story.

Sto solo dicendo che se la tua squadra teme di pianificare riunioni, probabilmente dovresti lasciar andare alcune delle "regole" della mischia.

A questa domanda è stata data una risposta esaustiva, ma è necessaria solo una cosa per farlo funzionare ed essere divertente.

Dai potere alla squadra. - vale a dire rendere loro il lavoro sulle cose che si pensano sono i più importanti.