Come rendere divertente la pianificazione dello sprint

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/204904

Domanda

Non solo i nostri incontri di pianificazione dello sprint non sono divertenti, sono addirittura terribili.

Le riunioni sono noiose e noiose e durano un'eternità (un giorno, ma sembra molto più lungo).
Gli sviluppatori se ne lamentano e temono le pianificazioni imminenti.

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

Come possiamo rendere le riunioni più piacevoli?

...

Qualche dettaglio in più, in risposta alle richieste di maggiori informazioni:

Perché gli elementi del backlog non vengono inseriti e non viene data loro la priorità prima del kickoff dello sprint?

Le storie degli utenti hanno infatti la priorità;non abbiamo idea di quanto tempo impiegheremo prima di suddividerli in compiti!Dalle (eccellenti) risposte 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é abbiamo sbagliato molto le stime delle storie, ma immagino che questo sia l'argomento per una domanda completamente diversa.

Perché gli sviluppatori si lamentano?

  1. Le riunioni sono lunghe.

  2. Le riunioni sono monotone.Storia dopo storia, compito dopo compito, faticando (sì, lottando) per valutare quanto tempo ci vorrà e cosa comporta.

  3. La stima delle attività fa sì che la stima della storia dell'utente sembri inutile.

  4. Più lunga è la riunione, minore è la concentrazione nella stanza.Meno i colleghi sono concentrati, più lunga sarà la durata della riunione.Si sviluppa una spirale ricorsiva di odio.Abbiamo preso in considerazione l'idea di dividere l'incontro in due giorni per mantenere le persone concentrate, ma gli sviluppatori non ne hanno voluto sapere.Un giorno di pianificazione è già abbastanza brutto;ora avremo due?!

Parte del nostro problema è che entriamo nei dettagli più piccoli (per ottenere stime più accurate).Ma quando facciamo una stima approssimativa, andiamo decisamente fuori strada!

Per riassumere la domanda:

  • Cosa stiamo facendo di sbagliato?

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

È stato utile?

Soluzione

Crea stima più facile

.

Break Your Sprint Planning Down.

fai bisogno per stimare le singole attività? Ho fatto Sprint Planning Due modi:

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

    3. dei due, preferisco la seconda opzione. Scopro che non stimare i compiti dà più libertà agli sviluppatori per far fronte alle modifiche. Se un'attività non ha più senso (quante volte hai scoperto che un compito non è stato già fatto in Uno sprint precedente) semplicemente buttilo senza alcuna penalità, oppure potresti dover cambiare un compito corrente in qualcosa di nuovo, eventualmente rompendolo. Sei davvero ridondante se stimati sia, come la somma dei compiti dovrebbe rappresentare i punti della storia e viceversa. Che valore guadagni davvero in questo altro che sapere quanto tempo impiegheranno i singoli compiti? Se ti ritrovi con taschi task che variano davvero abbastanza da fare la differenza, suggerirei di rompere quei compiti in pezzi più piccoli e più omogenei.

    Facendo questo, puoi abbattuto il tempo che spendi in Sprint Planning . Le storie si stimano stimate durante la pianificazione Sprint, e quando inizi lo sprint puoi mettere giù tutti i compiti a cui riesci a pensare a quella storia. Ovviamente se ci sono punti che incontri nella stima della storia che know dovrà essere affrontato in un compito, puoi aggiungerlo alle informazioni della storia e metterla come compito. .

    stima in unità ideali

    I punti della storia sono destinati a essere in Ideale unità come le ore di uomo ideale o giorni lavorativi ideali. Questi sono destinati a significare quello dato il giorno perfetto ogni giorno, dove non hai avuto interruzioni, nessun incontro, e tutto è andato secondo il piano, potresti realizzare il compito in X Giorni. Ora tutti sanno che questo semplicemente non è vero, ma la cosa meravigliosa delle statistiche è che non deve essere.

    Cosa intendo per questo è che dopo un po 'di tempo di stimare questi nei giorni ideali, ti rendi conto che forse ci vuole un ulteriore 25% del tempo che stima in media per completare una storia. Diciamo che avevi stimato 4 giorni di lavoro ideali, e invece ti è voluto 5. Nel tempo, tieni traccia di questo e poi hai un'idea approssimativa della conversione dai giorni ideali per i giorni reali. Il tuo primo istinto sarebbe quello di provare a compensare questo sopra stima, e probabilmente avresti sbagliato. La cosa principale qui è quella di rimanere coerente. In questo modo, la media a lungo termine rimane la stessa. A volte, a volte, sarà sotto e a volte sarà finita, Ma più stima, è meglio tu sei. Se ti trovi ancora può " T ottenere una stima decente, forse questo significa che non sai abbastanza della storia per stimarlo correttamente.

    Parla delle storie

    Quando si stima, Tutti dovrebbero avere un'idea approssimativa di ciò che dovrà essere fatto, dall'inizio alla fine, di ciò che ci vorrà per questa storia da completare. Non è necessario conoscere ogni dettaglio, ma abbastanza che pensi di te, te stesso, potrebbe intraprendere la storia. Se non hai quel livello di fiducia, probabilmente non dovresti esserlo stimato. Se dici "Beh, questa storia è troppo grande per noi per sapere la maggior parte dei dettagli", allora è un'indicazione che la storia è troppo grande, e dovrebbe essere suddivisa. Le storie, almeno nella mia esperienza, sono state abbastanza piccole che una persona, se necessario, potrebbe lavorarci da solo e realizzarlo entro una settimana o due.

    Questo anche aiuterà a risolvere il secondo punto nella modifica, che è troppa stima . Invece di stimare ogni singolo compito per ogni singola storia, stai semplicemente stimare la storia nel suo complesso, che dovrebbe aiutare a rimuovere molto la stima. Per quanto riguarda le riunioni meno monotoni, suggerirei di pianificare il poker, che puoi vedere maggiori informazioni su sopra.

    rendi la pianificazione più coinvolgente

    .

    stima usando la pianificazione del poker

    Per quanto riguarda la stima più divertente, hai provato a pianificazione del poker ? È il Modo che ho sempre fatto pianificare tutti i miei sprint su più squadre, ed è un buon modo per mantenere tutti coinvolti, poiché ogni persona deve almeno scegliere qualcosa. C'è anche una buona quantità di divertimento coinvolto quando tutti nella squadra prendono 3, e qualcuno mette giù un 20 e deve spiegare se stessi, o quando tutti nella squadra mette giù un 5 ma il manager mette giù un 8 (chi sosterrà Il capo quando vuole darti più tempo!).

    Per fare questo, Tutto ciò di cui hai bisogno sono alcuni schede di poker di pianificazione , che spesso effettuiamo sul retro delle schede indicizzate o utilizzando normali carte da gioco con valori collegati alle carte. Niente di speciale, e continua a sempre

Yone focalizzato.Ricorda semplicemente che cerca di fare qualsiasi compito per un intero giorno (incluso il poker di pianificazione) prende un pedaggio sulla produttività.Molti set di carte sono dotate di una carta da caffè per una ragione;Se qualcuno si sente bruciato, dai alla squadra una pausa per ricaricare e prenderlo quando tutti sono freschi!

In alternativa alle schede fisiche , puoi anche guardare schede elettroniche .I veri vantaggi qui sono il tracciamento automatico dei risultati, monitorando storie degli utenti da stimare e consentendo a tutti di mostrare le loro carte contemporaneamente per evitare "imbroglioni" (dove una stima di una persona è influenzata da un altro dovuto a poter vedere la loro carta).Ovviamente ciò richiede che tutti abbiano un computer e la possibilità di concentrarsi sul compito a portata di mano, quindi usalo a propria discrezione.

Altri suggerimenti

    .

  1. Perché gli elementi del backlog non sono inseriti e prioritizzati prima di Sprint Kickoff? sprecare i tempi degli sviluppatori non è divertente. Lascia che il tuo team conduca funzionare con il proprietario del prodotto e il project manager pochi giorni prima per dare la priorità alle cose. Questo vale per la pianificazione che è anche in ogni squadra sprint.

  2. Perché ci vuole un giorno per rompere le cose in compiti? Se hai una squadra ragionevolmente di dimensioni (2-4 sviluppatori, .5-1,5 qa persone per sviluppatore, 1- 2 MISC) Quindi dovresti avere 2-4 storie utente questo sprint. Trascorri 30 minuti o giù di lì con il proprietario del prodotto che chiariscono i requisiti, quindi 30 minuti o così rompendo i compiti a ~ 8 ore. Non inserire le attività durante la riunione. Basta essere d'accordo come una squadra quali sono i compiti sufficienti per le persone sane per capirli, che è responsabile per loro, e su quanto tempo dovrebbero prendere. Accetto che "quanto tempo dovrebbero prendere (compresi i test)" si adatta comodamente all'interno dello sprint.

  3. Se non è solo rompere le cose in compiti, cos'altro stai facendo? certo, retrospettive possono richiedere 30-60 minuti, ma sarà più breve quando le squadre entrano in una scanalatura.

    4. Così in sintesi - Smetti di sprecare il tempo delle persone e temono gli incontri un po 'meno. Oltre a quello, divertimento e compagno nella squadra non è qualcosa che puoi affrontare nelle riunioni. Vai a pranzo insieme, scherzare, mescolare le persone per avere una persona migliore per avere una personalità migliore, avere concorsi in crescita baffi ... Una volta che il morale è attivo, la gente farà naturalmente le riunioni di pianificazione sprint più lunghe.

La pianificazione è un'area di Scrum dove le squadre hanno molta flessibilità. Prova qualcosa di nuovo ogni sprint fino a quando non coluirai qualcosa che funziona per la tua squadra.

Alcune idee di successo Ho provato personalmente o sentito da altre squadre:

    .
  • Fai la creazione e la priorità della storia dell'utente senza l'intera squadra. Il proprietario del prodotto e / o il master di Scrum può gestire molto il lavoro occupato e lasciare che la squadra lo modifichi.
  • Rendi il tuo arretrato significativamente più lungo di un singolo sprint. Può richiedere un po 'di tempo per costruirlo, ma se il tuo arretrato è abbastanza lungo, la pianificazione delle riunioni è ridotta a fare piccoli modifiche o affrontare i recenti sviluppi aziendali.
  • ha riunioni di stima separati dalla pianificazione sprint. Se le persone pensano che gli incontri siano troppo lunghi, non c'è motivo per non dividerli.
  • Piano specificamente interrompe nell'agenda. Questo è utile se stai spesso sprecando tempo ad aspettare uno o due membri del team per tornare.
  • Break nel mezzo della riunione e assegna a tutti di attività fuori da una o due storie utente, quindi incontrarsi insieme per segnalare e ottenere consenso.
  • Assicurati che la tua riunione di pianificazione sia di quale da fare, non come per farlo. Gli ingegneri cadono molto facilmente nel secondo. Se è necessario, impostare incontri di progettazione separati dove discuti di come.
  • Separa le tue storie in indagine e implementazione. Pianificazione delle riunioni spesso vanno troppo a lungo quando i membri del team sanno troppo poco di ciò che continuerà e cerchere di capirlo durante l'incontro.
    Ad esempio, dì che avevi bisogno di integrare con un'API che il tuo team non ha esperienza con. Piuttosto che cercare di creare stime e compiti durante la riunione della pianificazione su qualcosa su cui sei incredibile, fai una storia di indagine per imparare l'API, fai una semplice app "Hello World" e insegnala alla squadra. quindi sarai attrezzato per pianificare il lavoro effettivo.
  • Tieni traccia durante le tue riunioni di questioni specifiche. Non solo "la pianificazione è noiosa", ma un livello di dettaglio come, "trascorriamo molto tempo a parlare di requisiti non chiari e nessuno sembra conoscere la risposta giusta". Quindi discutere quei problemi specifici nelle vostre retrospettive e il brainstorming per soluzioni specifiche. Rompere il problema fino a quando i pezzi non sono facili da risolvere.

Teniamo la nostra pianificazione sprint e retrospettiva allo stesso tempo, e sono quasi sempre fatti in 90 minuti, ma siamo una delle squadre più veloci. Facciamo una grande pianificazione a lungo termine a livello aziendale ogni 5 sprint che richiedono 4-6 ore. Ogni squadra è diversa, ovviamente, ma se stai spendendo un'intera giornata ogni sprint, c'è un sacco di spazio per il miglioramento.

Le tue sessioni di pianificazione sono troppo lunghe!

In base alla mia esperienza, una riunione di pianificazione sprint dovrebbe richiedere non più di 2 ore a settimana previsto (ad esempio, uno sprint di 2 settimane dovrebbe richiedere 1/2 giorni al massimo), ma quelli di successo dovrebbero essere più brevi di quello (metà di).

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

Un modo che ha funzionato per me:

    .
  • Introviale rapido allo sprint del PO
  • stima della capacità di sprint
  • Le storie hanno eseguito il down e la pianificazione del poker (timeboxed a 5/10 minuti per storia) fino a quando non ci sono abbastanza cose stimate per coprire lo sprint
  • Impegno / previsione ufficiale della squadra

Allora, in parallelo / paia / auto organizzato presso le nostre scrivanie, attività e stima del compito.

Nel mio lavoro precedente, l'intero primo giorno di ogni sprint (li chiamavamo iterazioni) era occupato da:

  • Retrospettiva. Abbiamo iniziato a farlo nel pomeriggio dell'ultimo giorno, ma spesso ci siamo ritrovati a fare retrospettive sullo sprint e poi a tornare al lavoro per sistemare gli ultimi punti in sospeso del lavoro di quello sprint, quindi abbiamo pensato che sarebbe stato meglio assicurarci che il il lavoro era tutto alle nostre spalle prima di retrospettivarci.Sembrava anche logico consolidare tutto il sovraccarico delle riunioni del processo Scrum in modo che gli altri giorni potessero essere pianificati e trascorsi in termini più ideali.In genere ciò richiedeva 2 ore.
  • Pianificazione dello sprint. Il backlog è stato stimato durante un Milestone Planning Meeting (che potrebbe durare un'intera giornata sia per gli sviluppatori che per i PO) ed è stata stabilita la priorità dai PO prima dell'inizio di ogni sprint.Abbiamo calcolato quanti giorni-giorni di sviluppo avevamo a disposizione (contabilità di ferie, ferie, ecc.), abbiamo preso il lavoro che pensavamo di poter svolgere dalla cima della pila e abbiamo rapidamente esaminato i requisiti degli utenti (precedentemente controllati dai nostri BA) per ottenere un'idea più completa di ciò che il lavoro ha comportato rispetto a quella che abbiamo ottenuto con la semplice panoramica durante l'MPM.In genere ciò richiedeva altre 2 ore.
  • Pianificazione delle attività. Conoscendo le storie e i criteri di accettazione, abbiamo suddiviso ciascuna storia in piccoli compiti stimati in ore ideali (un'ora trascorsa concentrandosi esclusivamente sul "svolgere" quel compito senza distrazioni o ostacoli).Il modo in cui la nostra scala di punti è stata calibrata, un 5 era uno sprint di sviluppatore, quindi un 1 poteva essere qualsiasi cosa fino a due giorni di sviluppatore inclusi.Per questo motivo è stato necessario scomporre praticamente tutto affinché i membri del team potessero mostrare i progressi sulla mischia.Questo è stato un altro blocco di 2 ore, con qualche scambio tra questo e l'oggetto successivo.
  • Schema AAT. I nostri PO e BA non erano programmatori e non codificavano.I PO si nascondevano dietro un contratto in cui si stipulava che avrebbero fornito i requisiti sotto forma di un modello Word e avrebbero collaborato con i BA per perfezionarli in quella forma.I BA capivano il codice, ma il loro tempo era dedicato esclusivamente all'analisi e al test finale (che richiedeva che il sistema esistesse, in modo da poter registrare le loro macro in Selenium).Quindi, per verificare che il nostro codice soddisfacesse i criteri di accettazione, abbiamo dovuto scrivere i nostri AAT modellando le azioni del test di accettazione "cartaceo".In genere lo facevamo nello stesso framework NUnit che usavamo per i test unitari e di integrazione (abbiamo provato FitNesse e non siamo riusciti a rinunciarvi abbastanza velocemente).Questo è stato il resto del nostro primo giorno di ogni sprint ed è continuato nel secondo.

Nel mio lavoro attuale, stiamo ancora adottando il processo Scrum, non avevamo una pianificazione delle tappe fondamentali a livello di team e molto di ciò su cui stiamo lavorando non ha criteri di accettazione rigorosi.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 cogliere le prime X ore ideali di lavoro dall'inizio.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 progettare soluzioni.Anche in questo caso, la pianificazione dello sprint è un'attività che dura tutta la mattina a lunedì alterni e il pomeriggio viene dedicato a eliminare eventuali ostacoli personali per poter iniziare seriamente lo sviluppo martedì.

Per rispondere effettivamente alla domanda dell'OP piuttosto che contrastare altri commenti/risposte dicendo che non dovrebbe volerci così tanto tempo, ci sono modi per affrontare la stima Agile, la pianificazione dello sprint e le retrospettive che sono un po' più interessanti di quanto potresti utilizzare.

Affrontare specificamente le tue preoccupazioni:

  • Le riunioni sono lunghe - Mettili in una scatola temporale.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 mantenere queste riunioni incentrate sull'argomento e proseguire per raggiungere gli obiettivi temporali.

  • Le riunioni sono monotone - Ce ne sarà un po';stai lavorando in piccoli pezzi, 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 ho sentito è che forse le tue riunioni di pianificazione dello sprint stanno cercando di ottenere troppo.Nella mia ultima azienda, la stima della storia veniva effettuata durante le "riunioni di pianificazione cardine", che si svolgevano circa una volta a trimestre e duravano tutto il giorno.In quelle riunioni, tutto ciò che si era accumulato sull'arretrato e che non avevamo stimato veniva stimato in punti.Se stai stimando la storia in punti e poi la stima dell'attività in ore, non vuoi farle entrambe contemporaneamente (magari nello stesso giorno).

  • Stimare le storie in punti e quindi le attività in ore sembra ridondante - Hanno due scopi diversi.Lo scopo della stima della storia è 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 suddividere le storie in cose che richiedono un giorno di sviluppo o meno (e quindi possono essere assegnate a un singolo ragazzo che ci si aspetterebbe di fare tutto in tempo), e assicurarsi di non averlo fatto hai valutato erroneamente la complessità di qualsiasi storia né hai fatto il passo più lungo della gamba nello sprint.

    Se tutte le tue storie durano un giorno o meno, allora è ridondante, ma non tutte le scale di punti sono calibrate allo stesso modo;nel mio ultimo lavoro, un 5 corrispondeva a due settimane-sviluppatore (perché all'inizio avevamo molti epici da stimare), che su scala lineare significava qualcosa fino a 2 giorni-sviluppatore.Considerato questo tipo di scala, praticamente tutto dovrebbe essere suddiviso in compiti.Nella mia nuova azienda, un punto è più vicino a mezza giornata per uno sviluppatore, quindi un 1 o anche un 2 è sicuramente un compito a sé stante, e 3-8 è nebuloso per quanto riguarda la forzatura del team a suddividerlo in compiti.

  • C'è un circolo vizioso in cui occorre più tempo per rendere le persone meno concentrate, quindi ci vuole più tempo - Time-box la tua time-box.Fai delle pause, proprio come dovresti fare quando programmi.Ogni 30 minuti, prenditi 5 minuti per sgranchirti le gambe, riorganizzarti, ecc.Puoi arrivare a dieci minuti ogni ora, ma non spingere troppo oltre il tempo della riunione.I tuoi ragazzi potrebbero avere fame, o aver bisogno di più caffè, o di andare in bagno, ecc.Non negarli;se glielo fai succhiare, scoprirai che le loro menti vagano.Oltre a ciò, anche mantenere le discussioni brevi, dolci e mirate aiuterà, come accennato in precedenza.

La riunione di pianificazione Sprint ha 2 parti:

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

    3. La prima parte è relativamente diretta, in base al numero di punti della storia che il team si sente che possono assumere, impegnarsi a completare molte storie degli utenti nel loro ordine di priorità.Fatto.

    La seconda parte è ciò che gli sviluppatori dovrebbero effettivamente divertirsi - elaborazione della storia e progettare la soluzione.I compiti cadono da questo.Quindi, avere il proprietario del prodotto, o qualsiasi qualsiasi PMI che abbia fornito spiegare una storia scelta.Poi hai quindi sviluppatore di subirlo, guidare la discussione del design.Utilizzare una tavola bianca.Rimbalzare le idee intorno.Divertiti.

    Questo è, davvero.Se le riunioni di progettazione non sono divertenti, allora c'è solo qualcosa di normale sbagliato.

Sì, lo so, la domanda è vecchia, ma ho una nuova risposta.:P

Dividi la riunione.

Abbiamo diviso il nostro incontro di pianificazione dello Sprint in 3 mini-riunioni separate

  • Eliminazione degli arretrati
  • Selezione della storia
  • Suddivisione dei compiti

Facciamo ciascuno di essi in un giorno diverso, subito dopo il nostro Daily Scrum: non appena il quotidiano è terminato, passiamo direttamente all'attività di pianificazione e poi siamo liberi da riunioni (regolarmente pianificate) per il resto della giornata.

Quindi sì, abbiamo pianificato a cascata :-O

Entrerò più in dettaglio su ciò che implica ciascuna sessione tra un secondo, ma lasciatemi spiegare come siamo arrivati ​​a questo.

Noi, come te, abbiamo avuto problemi con riunioni di pianificazione Sprint davvero terribili.Avevamo tutti gli elementi giusti, ma tutto ha richiesto un'eternità ed è stato davvero faticoso mentalmente ed emotivamente da superare.

Poi mi è venuta questa idea dopo aver letto questo articolo di Business Insider sul quotidiano di 5 minuti di Pivotal di suddividere le nostre riunioni in sessioni più brevi e di svolgerle all'inizio di ogni giornata.

Ne ho parlato con la squadra in una retrospettiva.Ad alcuni membri del team è piaciuto subito, altri erano un po' preoccupati, ma poi il nostro stagista ha menzionato alcuni studi di cui aveva letto la tecnica del pomodoro e ho iniziato a lavorarci sopra, e questo ha davvero aiutato l'idea a prendere piede.

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

E ha funzionato!Lo stiamo facendo da circa 6 settimane su due progetti separati (6 sprint di due settimane in totale) e ha fatto un'enorme differenza.
Siamo più produttivi.Risparmiamo un sacco di tempo.
Otteniamo risultati migliori.E non temiamo più i nostri incontri di pianificazione.

E onestamente, il nostro tempo di 25 minuti è piuttosto vago: alcune sessioni vanno molto veloci, come 5-10 minuti in alcune delle nostre sessioni di toelettatura, e alcune durano più a lungo, come quando finiamo per identificare nuove storie o dover spezzare le storie. e rivalutare durante la negoziazione.Nel complesso, però, di solito non dura in media più di 1,5 ore per l'intera faccenda, e penso che sia per questo che funziona così bene.

Passiamo ai dettagli.....

Eliminazione degli arretrati

Abbastanza semplice: esaminiamo le storie con la massima priorità, parliamo di ciò che comportano e ci assicuriamo che le nostre stime siano buone.

Se necessario, rivaluteremo le storie, ad esempio se abbiamo stimato qualcosa mesi fa e dopo aver realizzato cosa ha effettivamente richiesto una storia simile, potremmo accettare di rivalutare.(noi usiamo punti della storia senza unità a proposito, e noi non stimare i compiti).

Inoltre, se il PO ha aggiunto nuove storie che ritiene siano di alta priorità, questo è il momento di valutarle.

Poiché non effettuiamo la selezione della storia fino al giorno successivo, questo processo dà al PO un po' di tempo in più per esprimere un giudizio finale su ciò che è più importante da portare a termine nell'iterazione successiva - e questo si è rivelato molto utile.

Questo incontro tende a durare poco con alcuni PO e lungo con altri.(personalmente, penso che sia un ottimo indicatore dell'odore di come sta andando il tuo PO)

Selezione della storia

Prendi il tuo Chris Voss avanti, è il momento di negoziare.

In questo incontro, prendiamo le storie con la massima priorità e definiamo a Dipartimento della Difesa per ciascuno.Negoziamo ciò che ciascuna comporterà, suddividendo e combinando le storie secondo necessità, finché non saremo tutti d'accordo sui nostri obiettivi Sprint.

Traiamo molti benefici dall'avere una mente fresca e quell'energia del buongiorno per questo incontro - e sapere che svolgeremo i compiti un altro giorno ci consente di dedicare il tempo di cui abbiamo bisogno per negoziare davvero bene e comprendere i nostri impegni.

Compiti

Ok, quindi sarò il primo a dirlo, i compiti erano miei MENO parte preferita della pianificazione nelle nostre vecchie riunioni di un giorno.

Semplicemente non abbiamo mai fatto il nostro passo con questo.Abbiamo provato a salvare le attività fino alla fine della riunione, ma a quel punto eravamo tutti esausti ed è stato davvero improduttivo.Abbiamo provato a definire i compiti contemporaneamente al nostro Dipartimento della Difesa durante la negoziazione, ma lo abbiamo trovato troppo distraente e macchinoso: ci saremmo esauriti prima di selezionare tutte le storie.Inoltre, è stato davvero difficile continuare a spostare l'attenzione/il pensiero avanti e indietro tra stima, negoziazione, selezione della storia e generazione di attività.Abbiamo lottato, ed è stato uno schifo e ha reso i nostri incontri terribili.

Ma ora, definendo il DoD in un giorno e non svolgendo attività fino al giorno successivo, non ci esauriamo, siamo sempre nel giusto stato mentale e ci dà un'intera giornata per marinare la storia e riflettere davvero e comprendere tutte le attività prima di iniziare.

Questo da solo, IMHO, è un punto di svolta totale.

Mettere tutto insieme.

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

  • Lunedì - Daily scrum -> Sprint review
  • Martedì - Mischia giornaliera -> Eliminazione dell'arretrato
  • Mercoledì - Daily scrum -> Selezione della storia
  • Giovedì - Daily scrum -> Compiti
  • Venerdì - Daily scrum -> Retrospettiva

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

Stiamo avendo uno sprint settimanale con una riunione di un'ora in cui discutiamo lo sprint precedente, ciò che è lasciato a fare e poi passare alla pianificazione della prossima settimana. Tutto entro un'ora.

Questo è ovviamente perché abbiamo scoperto che nel nostro caso seguendo scrum troppo rigorosamente sprecare troppo tempo.Questo perché la maggior parte delle storie sono già discusse con i nostri membri del team quando il richiedente crea la storia dell'utente.

Sto solo dicendo che se il tuo team termina le riunioni di pianificazione, probabilmente dovresti lasciare andare alcune delle "regole" di Scrum.

Questa domanda è stata risposata in modo completo, ma è necessaria solo una cosa per farlo funzionare e sii divertente.

Dare il potere alla squadra. - I.e. Effettini loro di lavorare su cose che loro pensano che siano i più importanti.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
scroll top