Se gli sprint sono in media 10 giorni, perché spesso suggeriscono che le storie siano ridimensionate a 2-3 giorni?
Domanda correlata: Come gestire gli elementi del backlog che sono più lunghi di uno sprint?
Se gli sprint sono in media 10 giorni, perché spesso suggeriscono che le storie siano ridimensionate a 2-3 giorni?
Domanda correlata: Come gestire gli elementi del backlog che sono più lunghi di uno sprint?
Quando si calcola, le attività più lunghe hanno più spazio per la variabilità. Variabilità significa un sacco di cose - qualcuno si ammala e prende un giorno libero, qualcuno viene coinvolto in riunioni, qualcuno deve supportare un altro progetto, è necessario condividere risorse con altre persone o team ... la lista continua. Riducendo il lasso di tempo per una data attività, stai cercando di ridurre il tempo in cui le persone che fanno il lavoro possono essere allontanate o bloccate dal lavoro che stai valutando.
Questa idea non è esclusiva di Scrum (o di qualsiasi metodo Agile). Fa parte di qualsiasi buona tecnica di stima per qualsiasi progetto di ingegneria. Avere compiti a grana più fine tende a fornire stime più accurate e questa accuratezza si fa scoppiare.
Hai qualche riferimento per "le storie spesso suggerite essere ridotte in media a due giorni"?
Ho visto alcune persone suggerire che le attività dovrebbero prendere al massimo un giorno per finire. Il punto principale è che siamo pessimi a stimare e più a lungo ci penserai ci vorrà per finire il compito, più è probabile che tu possa commettere un errore.
Puoi trovare ulteriori informazioni su:
e
why is it often suggested stories be sized to 2-3 days?
Mi chiedo davvero dove hai ricevuto questo suggerimento perché è sbagliato. Ci sono generalmente due problemi con questo suggerimento:
Entrambi questi problemi violano il semplice principio di stima usato nelle metodologie agili: non sai in anticipo quanto tempo hai bisogno per completare una storia. Stai solo cercando di confrontare le dimensioni (complessità) delle storie nel tuo arretrato e durante la pianificazione della riunione ti impegni a scrivere poche storie con priorità che ritieni di poter completare durante lo sprint. Dopo il completamento dello sprint, esaminerai il numero di storie utente che hai completato e potrai fare ipotesi sul tempo necessario per completare altre storie: più sprint farai, più precisa diventerà l'ipotesi. Come la tua ipotesi sul tempo reale necessario per completare la storia, migliorerai anche il tuo impegno.
Per questo motivo le persone usano misure relative per stimare storie come punti storia o t-shirt e calcolare il tempo medio necessario per fornire un punto storia o un'altra unità. Con una stima costante, dovresti stabilizzare il tempo medio di consegna di un punto della storia entro 3-4 sprint.
Poiché l'unità è relativa, non è necessario utilizzare la stessa scala per tutti i progetti. Di solito inizi con una singola user story, sei più sicuro del suo contenuto e prendilo come etalon con una certa dimensione. Continuerai quindi a stimare altre storie confrontandole con il tuo etalon e altre storie già stimate per selezionare la dimensione prevista. In caso di story point userai di solito alcune sequenze di dimensioni attese come Fibonacci perché, man mano che la tua storia diventa più complessa, è più difficile da stimare e contiene molta più incertezza. Le grandi storie dovrebbero essere scomposte come descritto nella domanda collegata.
Più grandi sono le storie, meno accurate sono le tue stime.
Personalmente, li spezzerei ancora più in basso di così.
Leggi altre domande sui tag estimation scrum user-story sprint