Con agile, cosa succede quando una storia utente non viene completata in una iterazione? [duplicare]

Nelle mie esperienze, le storie sono state fatte o meno. Non esiste il concetto di una storia incompleta. Alla fine di uno sprint, hai completato la progettazione, l'implementazione, il testing, l'integrazione e il testing del sistema per una storia e l'hai presentata al cliente per l'approvazione, a quel punto è stata spostata dall'arretrato o è rimasta in l'arretrato per il prossimo sprint. Non c'era alcun concetto di ri-stima o storie parzialmente completate.

All'inizio della successiva iterazione, una storia di N point iniziata nella precedente iterazione e lasciata incompiuta era ancora considerata una storia a punti. La nostra velocità per lo sprint precedente è stata utilizzata per tirare giù un numero appropriato di punti storia per il prossimo sprint, iniziando con i N punti incompleti e le storie migliori fino a quando il numero di punti storia nell'iterazione era la velocità dei punti precedenti. / p>

Tuttavia, questa era solo la nostra pratica. La chiave è essere coerenti. Qualunque cosa scegliate, fatelo ad ogni iterazione e non cambiate - ciò influenzerà il vostro modo di calcolare la velocità e stimare il lavoro per gli sprint futuri.

Sposta la storia alla successiva iterazione. Forse aggiorna la sua dimensione, se è stata eseguita una buona quantità di lavoro su di essa.

La dimensione di iterazione è presumibilmente corretta. L'approccio migliore (secondo me :)) è dividere. In genere, quando le attività non vengono completate all'interno dell'iterazione a cui sono assegnate, suggerisco di dividere le storie utente e spostare le attività incomplete alla successiva iterazione. La stima della nuova storia utente viene calcolata dalle unità rimanenti necessarie per completare la storia utente originale. In questo modo puoi mantenere le stime e anche conservare riferimenti storici.

A. Metti la storia nel backlog del progetto. Se è ancora la cosa più importante, sarà programmata per il prossimo sprint. In caso contrario, il proprietario del prodotto pianificherà qualcosa di più prezioso.

B. Non ottieni punti per quella storia per questo sprint. Quando pianifichi il prossimo sprint, contano solo i punti per le storie completate in questo sprint. (Sì, inserirai una storia bonus alla fine del prossimo sprint.) Grande, ma è meglio avere una storia bonus piuttosto che presumere che avrai finito, quindi avrai un'altra storia incompleta da prendere in considerazione .)

Puoi spostare la storia alla successiva iterazione e stimare di nuovo. Puoi sempre discutere con il proprietario del prodotto / team e scrum master cosa fare.

Oltre alle altre risposte, potresti

1) crea una storia per rappresentare il lavoro completato e una nuova per il resto del lavoro, aggiustando le stime.

2) analizza il motivo per cui vi è stata una stima errata. Le storie rappresentano in genere gli impegni, e se un impegno non è stato raggiunto, è un po 'brutto. Non c'erano abbastanza analisi in anticipo (cioè gli sviluppatori non sapevano quanto lavoro sarebbe stato effettivamente), le persone si sono ammalate, altri bug hanno impedito il lavoro, ecc.?

Se la storia non è completa (come nella definizione di fatto), non dovresti ricevere alcun punteggio da essa.

Nel prossimo sprint, crea una nuova storia basata su ciò che è rimasto da quella incompiuta, aggiungila allo sprint backlog e stimala. Possibile unirlo a un'altra storia se è troppo piccola.

Se il tuo strumento non è in grado di gestirlo, probabilmente dovresti cercare qualcosa che possa farlo. Preferisco strumenti low-tech personalmente.

Il dilemma: dove vanno i racconti per le storie non finite? Lo sprint dove sono finiti? Credito parziale in ogni sprint per la parte terminata in ogni sprint? Ecco come ho risposto al dilemma in un post sul blog:

Questi punti non vanno da nessuna parte. Niente credito. Ma la squadra deve completare il lavoro.

Blog completo su questo argomento qui: link

Tendiamo a frenare le storie in modo che possano facilmente adattarsi allo sprint e che possano essere facilmente rimosse. Ci vuole una certa mentalità per frenare la storia in pezzi realizzabili durante la riunione di pianificazione sprint.

La cosa che ho trovato è che se le storie si frangono in pezzi consegnabili (che possono essere visibili o meno, o addirittura spenti per un paio di scatti), il mio team può fare tutto il lavoro sul bagagliaio, e non problemi con il lavoro su un ramo e poi rebase / unisci il lavoro più tardi, il che è sempre un problema, quindi questo è un bonus.

Facciamo una variazione su alcune delle risposte fornite.

Stimi uno sprint con una determinata quantità di punti, diciamo 34. Se dopo aver raggiunto il punto finale designato per lo sprint e non abbiamo finito, entriamo in uno sprint correttivo.

Ciò significa:

1. Otteniamo crediti per i 34 punti.
2. Dobbiamo finire la storia su cui stavamo lavorando. Era il massima priorità sul backlog al momento dell'assegnazione, quindi mantiene quella priorità.
3. Lavoriamo e lavoriamo sulla storia data finché non incontriamo la nostra definizione di fatto. Questo ammontare di tempo è assegnato a 0 punti storia. Questo serve per regolare la nostra velocità.

1. Alla recensione sprint, il Product Owner, in consultazione con il Il team di sprint e le parti interessate prendono la decisione sul fatto. Nel In questo caso, l'OP dichiara che la storia non incontrerà il esigenze del cliente come previsto.
2. Il PO può scegliere di creare una nuova storia e inserirla nel backlog Prodotto . La nuova storia, come ogni storia, si basa sul informazioni che l'OP ha sullo stato attuale del prodotto e le esigenze attuali del cliente. Questo include ovviamente il discussione che ha avuto luogo sulla storia incompleta di cui sopra.
3. Alla prossima riunione di pianificazione, la nuova storia viene valutata come qualsiasi altro. L'ordine di priorità viene assegnato e il team stima lo sforzo.

Note:

1. Il grado di soddisfazione è un fattore nel processo decisionale. Ad esempio, se il team accetta di essere "un'ora" da completamento, il PO può accettare di ritardare la decisione presa. Ma il il team deve ancora dimostrare che la trama è fatta!
2. Nella mia squadra, una storia non viene mai spostata fuori dallo sprint dopo la revisione di sprint (è chiusa così com'è). Usiamo il tasso "fatto-fatto" da usare come punto di discussione durante la retrospettiva. Se spostassimo la storia, sembrerebbe che il nostro tasso di completamento fatto fosse al 100% ogni scatto.

Quindi ci sono due modi per farlo

INIZIALE - Dividi le storie e assegna e dividi i punti alla storia divisa vecchia e nuova - questo significa stimare il lavoro rimanente sulla storia

Ad esempio - Una storia di 8 puntatori era "incompiuta" con solo 3 punti di lavoro completati e il team stima che 5 punti sono necessari per il lavoro in sospeso / rimanente - Quindi aggiorna la storia "incompiuta" a 3 punti e la nuova divisione storia a 5 punti .... ha un senso?

SECONDO: dividere la storia e azzerare i punti della vecchia storia e aggiornare la nuova divisione con i punti pieni della vecchia storia: questa è la squadra che segue le migliori pratiche. Il credito viene fornito solo quando l'intera storia è completata e anche la velocità può essere acquisita correttamente facendo una media una volta completate alcune iterazioni.

La seconda opzione è ciò che seguiamo