Cosa fare con la stima di una storia incompleta?

Faccio parte di un team di sviluppo relativamente nuovo Scrum, supponiamo che alla fine dello sprint alcune grandi storie siano in progresso non siano state acceptedfatte dall'OP.

In primo luogo, cosa succede con le storie degli utenti? Li porti semplicemente allo sprint successivo?

In tal caso, dovrebbero essere rivalutati? A mio avviso, il lavoro rimasto su queste storie utente può essere minimo o molto? In caso contrario, perché no?

EDIT: Nel mio caso specifico, le storie non sono state completate a causa di un impedimento che è durato alcuni giorni, non a causa della sottovalutazione delle storie degli utenti. Per quelli di voi che possono aiutare, stiamo usandoVersionOne

agile scrum

— ediblecode
fonte

Lavoro con un processo XP e mi sono chiesto quale sia il modo migliore per affrontare questo tipo di situazione

— chrisbunney,

La mancata identificazione di un impedimento come possibile rischio e la determinazione dell'esposizione al rischio RE (impatto * probabilità) indica un problema di stima. Una user story con un alto RE deve avere un buffer più ampio di costi e tempi associati ad esso per far fronte a tali rischi, qualora dovessero svilupparsi in problemi.

— Thomas Owens

raddoppiale e aggiungi 32, proprio come C => F

— Paul

Risposte:

In primo luogo, cosa succede con le storie degli utenti? Li porti semplicemente allo sprint successivo?

Dipende. Se nessun'altra storia ha una priorità più alta, allora sì, vengono spostati nello sprint successivo. Se altre storie hanno una priorità più alta, potrebbero essere spostate indietro nel backlog del prodotto se non c'è abbastanza spazio nello sprint per adattarle. Tutto ciò accade nella pianificazione dello sprint, in base alle priorità assegnate a ciascuna storia dal proprietario del prodotto. Poiché uno degli scopi di metodi agili come Scrum è massimizzare il valore fornito riducendo al tempo stesso, tutto si riduce a quanto valore viene aggiunto finendo quelle storie.

Indipendentemente da ciò che accade, è ancora necessario lottare per un prodotto potenzialmente spedibile alla fine dello sprint. Ciò potrebbe significare il rollback per garantire che il prodotto di fine sprint superi tutti i test e che le funzionalità complete siano completamente utilizzabili dall'utente senza problemi significativi.

In tal caso, dovrebbero essere rivalutati? A mio avviso, il lavoro rimasto su queste storie utente può essere minimo o molto? In caso contrario, perché no?

Non rivaluterei perché, in Scrum, stimhi una storia quando la accetti, inizi a lavorare e non hai un concetto di parzialmente completo . Una storia è completa al 100%, testata e accettata (fatta) o non è fatta. Se non esiste un concetto di parziale completo, non è possibile determinare la quantità di lavoro rimanente nella storia. Sembra che neanche io sia solo in questo pensiero . Hai stimato il lavoro che pensavi di poter fare, quindi lascia entrare questi dati e cerca di capire perché la stima è stata interrotta nel tuo sprint postmortem e cerca di evitare di commettere quell'errore per gli sprint futuri.

— Thomas Owens
fonte

L'abbiamo sperimentato solo una volta, e non aveva a che fare con la stima sbagliata, avevamo un tipo di impedimento che ha portato al lavoro svolto, ma non testato.

— codice edibl

@ user1016253 Ciò significa che il preventivo ha avuto un problema. Le stime dovrebbero includere l'esposizione al rischio (impatto * probabilità = esposizione, in cui l'esposizione ha un impatto su costi, tempi e qualità). Poiché si è verificato un impedimento, ma la stima non ne ha tenuto conto (o non ne ha tenuto conto in misura sufficiente), qualcosa è stato trascurato o valutato male (l'impatto o la probabilità erano troppo bassi, il che significa che l'esposizione era troppo basso, il che significa che non c'erano risorse sufficienti allocate per identificare e correggere il problema quando si è verificato).

— Thomas Owens

@ user1016253 E se si riscontrano problemi con la stima e la visualizzazione di rischi e potenziali blocchi stradali, forse una buona idea sarebbe quella di scomporre la storia, in più storie che ognuna inserisce nel backlog o nelle sottostorie che possono essere utilizzate solo dal team di sviluppo per capire il lavoro che deve essere fatto. Spesso è più semplice stimare ed eseguire analisi dei rischi su un'unità di lavoro più piccola.

— Thomas Owens

@Thomas Owens: Questo non sembra essere un modo utile per gestire il rischio per me. In particolare, un evento a bassa probabilità che non è catastrofico è una bassa esposizione, e quindi anche un progetto ben gestito può essere scartato un po 'fuori programma in certe occasioni. Se non corri mai un rischio, otterrai molto poco. Ovviamente il monitoraggio delle stime deve evitare di accettare tali scuse, altrimenti finisci per fare stime valide solo quanto gli investimenti che hanno portato al recente crollo del mutuo, e per le stesse ragioni

— David Thornley,

@DavidThornley Non è affatto un modo per gestire il rischio, ma un punto di partenza per un piano di gestione del rischio che includa anche strategie di rilevazione e mitigazione. È una tecnica utilizzata per garantire che tu abbia tempo e denaro sufficienti nel tuo piano qualora i rischi si sviluppino in problemi. È sostenuto da Steve McConnell in Software Estimation e Karl Wiegers in questo documento . È importante rendersi conto che non è un buffer per attività, ma un buffer di progetto (o iterazione) nel caso in cui si dovessero presentare vari rischi.

— Thomas Owens

In genere, spetta al maestro Scrum eletto decidere cosa devono diventare i compiti che hanno superato uno sprint, ovviamente dopo aver consultato il resto del team e lo sponsor del progetto / proprietario del prodotto. Alla fine di uno sprint, è tempo di rivedere quali sono le priorità. È possibile che la storia in questione abbia una priorità inferiore rispetto a una storia nuova / esistente e debba essere rimessa sul tracker come "in corso" o qualunque etichetta venga utilizzata dal tracker, indicando che questa storia deve essere seguita in un altro punto in tempo. In alternativa, la storia può essere completamente descritta. Non hai menzionato il tracker che stai utilizzando, ma la maggior parte di quelli che ho visto ti consentono di impostare una storia su "decodificata" se non fa più parte del progetto.

In secondo luogo, dal momento che il tuo team è nuovo su Scrum, questo fa tutto parte del processo di apprendimento. Ora hai riconosciuto che alcune storie sono troppo grandi, quindi il tuo team impiegherà più tempo a scomporle. È in genere compito dello scrum master assicurarsi che ciò accada. Lo Scrum master dovrà anche consultare lo sponsor del progetto / il proprietario del prodotto con storie incomplete per cercare di analizzarle ulteriormente o ottenere l'ultima parola sulla loro disconnessione completa.

Nel mio team, ogni 2 settimane (sprint) viene eletto un nuovo maestro Scrum, in modo che tutti possano provare a gestire le attività, organizzare riunioni Scrum e assicurarsi che tutti presentino rapporti sullo stato di avanzamento. Spero che sia il caso nella tua squadra, è sicuramente una bella esperienza.

— Pianeta Desolato
fonte

Nitpick: la decisione su cosa fare della storia incompleta è una questione di priorità. Quindi credo che il proprietario del prodotto dovrebbe decidere questo, non lo Scrum master.

— sleske,

@sleske - Concordato. Avrei dovuto renderlo più chiaro nella mia risposta. Inizialmente ho detto che il maestro della mischia avrebbe consultato il team, ma avrei dovuto includere lo sponsor / proprietario del progetto, che ho corretto. Grazie per la testa però.

— Desolato pianeta

Se le storie incomplete sono ancora incomplete alla fine di uno sprint, non puoi davvero scomporle a quel punto perché è probabile che ciò sovvertisca completamente la Definizione di Fatto - "Quindi stai dicendo che parte della storia è Fatto? Ma non è stato ancora rivisto il codice! " Questo è il motivo per cui epiche come storie singole sono orribili e non dovrebbero mai essere consentite negli sprint.

— Robin Green,

@RobinGreen Sono d'accordo con la tua opinione sulle epopee e non ne sono un fan. Una delle cose chiave (qualcosa con cui molte persone con cui ho lavorato trascurano) è il valore delle retrospettive. Di recente abbiamo iniziato a utilizzare la scheda Agile di JIRA e spesso faccio vedere al team il grafico delle prestazioni del team. Le storie incomplete vengono discusse se e quando accadono e immediatamente reinserite nel backlog. Nella retrospettiva, esaminiamo perché la storia era incompleta. Mancanza di risorse? Mancanza di conoscenza? o forse una combinazione libera dei due.

— Desolato pianeta,