Cosa fare con la stima della storia incompleta?

11

Faccio parte di un team di sviluppo relativamente nuovo a Scrum , supponiamo che alla fine dello sprint alcune grandi storie siano o in progress o non fossero accepted dal PO.

In primo luogo, cosa succede a queste storie di utenti? Li porti semplicemente nel prossimo sprint?

In caso affermativo, dovrebbero essere rideterminati? Secondo me, il lavoro che rimane su queste storie di utenti 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 di alcuni giorni, non a causa della sottostima della user story. Per quelli di voi che può aiutare, stiamo usando VersionOne

    
posta ediblecode 03.01.2012 - 13:49
fonte

2 risposte

13

Firstly, what happens with those user stories? Do you just carry them over into the next sprint?

Dipende. Se nessun'altra storia ha una priorità più alta, allora sì, vengono spostati nel prossimo sprint. Se altre storie hanno una priorità più alta, allora potrebbero essere spostate nel backlog del prodotto se non c'è spazio sufficiente nello sprint per accoglierle. Tutto ciò avviene nella pianificazione dello sprint, in base alle priorità assegnate a ciascuna storia dal proprietario del prodotto. Poiché uno degli scopi dei metodi agili come Scrum è quello di massimizzare il valore erogato riducendo il tempo, tutto si riduce a quanto valore viene aggiunto terminando tali storie.

Indipendentemente da ciò che accade, devi comunque cercare un prodotto potenzialmente spedibile alla fine dello sprint. Ciò potrebbe comportare il rollback per garantire che il prodotto end-of-sprint superi tutti i test e che le funzionalità completate siano pienamente utilizzabili dall'utente senza problemi significativi.

If so, should they be re-estimated? In my view the work remaining on these user stories can be minimal or a lot? If not, why not?

Non vorrei rianimare perché, in Scrum, stimerai 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 vi è alcun concetto di parziale completamento, non è possibile determinare il lavoro rimanente nella storia. Sembra che Non sono solo in questo pensiero , neanche. Avete stimato il lavoro che pensavate di poter fare, quindi lasciate questo data point e fate un punto per discutere del motivo per cui la stima è stata disattivata nel postmortem dello sprint e cercate di evitare di commettere quell'errore per gli sprint futuri.

    
risposta data 03.01.2012 - 14:06
fonte
1

In genere, spetta allo Scrum master eletto decidere quale sarà il risultato delle attività 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, è il momento di rivedere quali sono le priorità. È possibile che la storia in questione abbia una priorità minore rispetto a una storia nuova / esistente e deve essere reinserita nel tracker come "in corso" o in qualsiasi etichetta 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 quale tracker stai usando, ma la maggior parte di quelli che ho visto ti permettono di impostare una storia da 'descoped' se non fa più parte del progetto.

In secondo luogo, poiché il tuo team è nuovo in Scrum, tutto questo fa parte del processo di apprendimento. Ora hai riconosciuto che alcune storie sono troppo grandi, quindi il tuo team impiegherà più tempo per rompere le storie. In genere è l'onere dello scrum master per assicurarsi che ciò accada. Lo Scrum master avrà anche bisogno di consultare lo sponsor del progetto / proprietario del prodotto con storie incomplete per cercare di suddividerle ulteriormente o ottenere l'ultima parola sulla loro completa descoping.

Nella mia squadra, un nuovo Scrum master viene eletto ogni 2 settimane (sprint), in modo che tutti possano dare una mano a gestire le attività, organizzare riunioni di Scrum e assicurare che tutti inviino rapporti sui progressi. Spero che sia il caso della tua squadra, è sicuramente una bella esperienza.

    
risposta data 03.01.2012 - 14:13
fonte

Leggi altre domande sui tag