Abbiamo terminato lo sviluppo e chiuso lo sprint (due settimane). Ma il codice non è stato revisionato. Quindi nella terza settimana non iniziamo un nuovo sprint e manterremo pulito (refactoring) il codice. Lo scrum master ci ha detto che possiamo ancora registrare il tempo per le attività precedenti.
La mia domanda è che poiché chiudiamo lo sprint, ha effetto il grafico di burn-down dello sprint?
Se la tua definizione di fatto ( 1 , 2 , 3 ) richiede che tu riveda la tua implementazione per completare una storia, quindi non puoi prenderti il merito di completare la storia e il grafico di burn down non riflette un completamento storia. Tieni presente che una storia utente è completata o meno e il grafico di masterizzazione non riflette il credito per il completamento dei punti fino a quando la definizione di fatto non viene soddisfatta e la storia è completa.
Suggerirei comunque di dare un'occhiata al tuo processo. Se hai iniziato così tante storie che non potresti chiuderle adeguatamente, sembra che tu stia prendendo troppo lavoro. Stimate la vostra intera definizione di fatto nei vostri punti storia? Stai modificando i tuoi punti storia per lo sprint in base alla velocità della tua squadra? I tuoi sprint sono troppo brevi (dovresti pianificare uno sprint di 3 settimane invece di due)?
Hai chiuso lo sprint o no? Estendendolo a una terza settimana sembra che tu stia ancora lavorando, a meno che tu non abbia uno sprint di una settimana per la revisione del codice. In ogni caso ... a chi importa. Se tutti i tuoi sprint misurano la creazione del codice (e tutta la revisione viene eseguita in seguito) allora sì, chiudi il grafico di burndown e ne inizi uno nuovo quando inizi il tuo prossimo sprint.
Il punto del burndown è misurare quanto effettivamente hai fatto rispetto a quanto pensavi di fare. È tutto. È solo uno strumento per aiutarti a pianificare il tuo prossimo sprint.
Alla fine della giornata, se stai ancora lavorando a uno sprint precedente alla settimana 3, è ancora attivo. La maggior parte degli sprint è stata progettata con i requisiti di refactoring e revisione del codice già in mente. Se venite a scoprire che il vostro refactoring / revisione del codice sta sanguinando in un'altra settimana, suggerirei di adattare la previsione dei punti del vostro team per risparmiare tempo per quei processi (piuttosto importanti).
Per rispondere in modo più diretto alla tua domanda: no, non penso che influenzi il burndown a causa della tua situazione attuale, ma dovrebbe. Regolare / iterare i tuoi processi per salvare la tua squadra abbastanza tempo per gestire tutti i requisiti di sprint durante il suo tempo assegnato.
Leggi altre domande sui tag agile