Scrum sopravvalutazione e ripianificazione

Uno degli scopi di avere un grafico di burndown è mostrare come, nel tempo e in modo trasparente, viene offerto un valore.

Le storie dei nuovi utenti non erano all'inizio, quindi sembra un po 'complicato fingere che lo fossero. Aggiungendoli nel grafico di burndown in questo momento, stai mostrando con precisione che il livello attuale di stima è ancora un po 'nelle sue fasi evolutive preliminari.

Questo è un bene per te e per il proprietario del tuo prodotto. Mostra e mostrerà come l'uso di questo sistema di gestione del progetto ha permesso di diventare migliori stimatori.

Sarai in grado di vedere fin dall'inizio che stavi valutando, poi sottostimando, poi sovrastimando un po 'di più ma un po' meno ... e alla fine vedrai i miglioramenti nella stima man mano che procedi.

Penso che la stima delle storie degli utenti sia una delle parti più difficili di uno sprint e solo quando il tuo team imparerà a evolvere insieme diventerà sempre più efficiente nel processo. È bello averlo dimostrato attraverso gli strumenti che stai utilizzando, come il grafico di burndown.

Non ti farà male se annulli lo sprint e pianifichi lo sprint successivo prendendo in considerazione la tua velocità attuale.

Dalla Guida di Scrum ufficiale:

Sprints can be cancelled before the Sprint time box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Team, or the ScrumMaster.

Dato che la pianificazione dello sprint dovrebbe essere eseguita all'interno di una discussione con il proprietario del prodotto, il supervisore e il team, sarebbe controproducente scegliere semplicemente le storie utente successive.

Nel caso tu fossi leggermente in anticipo, avresti potuto scegliere la storia con la priorità più alta, ma qui la tua situazione è molto diversa.

Puoi aggiungere un grafico per la masterizzazione . Mostrano, senza ambiguità, quando e quanto nuovo lavoro hai aggiunto:

Questo grafico mostra che il team ha aggiunto altri 20 punti di lavoro nell'iterazione 5. Questa immagine mostra le iterazioni, ma funziona altrettanto bene con i giorni.

Esistono diverse tecniche per visualizzarlo.

Uno di questi è di introdurre un offset all'asse y (l'asse orizzontale) nel giorno in cui sono state aggiunte le nuove storie, con il grafico di burndown effettivo che scende al di sotto del livello "0" originale.

Un altro è far finta di essere lì dall'inizio (che è molto più semplice da usare con i grafici di burndown basati su CGI).

E potresti inventare il tuo.

La cosa più importante è discuterne tra il team, il mischia e il proprietario del prodotto per raggiungere un accordo su ciò che si vuole fare in questa situazione. Non esiste un modo assolutamente fisso per fare qualcosa nella mischia oltre alle regole di base. Scrum ha lo scopo di evolvere nel tempo per soddisfare al meglio le esigenze del tuo ambiente.

Mi piacerebbe suddividere il problema dell'OP in tre domande distinte:

1. Continua o annulla lo sprint?
2. Che cosa fare nella settimana restante se lo sprint continua?
3. Come pianificare il prossimo sprint?

I grafici di burndown e burn-up citati in altre domande, sebbene utili, sono secondari rispetto agli OP "che cosa facciamo ora?"

Continua o cancella : sono qui con Pierre, è opportuno cancellare questo sprint e iniziare subito a pianificare il prossimo. L'annullamento di Sprint non è un'opzione se ci sono altri team e gli sprint devono essere sincronizzati (la maggior parte dei guru Scrum consiglia di sincronizzarli).

Se lo sprint continua: Limita i lavori in corso . Lavora su una sola storia alla volta, concentrati sulla finitura, per la quale hai meno di una settimana. Assicurati che non ci siano storie in uno stato parzialmente completato alla fine dello sprint.

Come pianificare il prossimo : le opzioni qui sono per provare la stima relativa delle dimensioni o usare l'equivalenza story-point-person-day e il focus factor come un'approssimazione come descritto in Henrik Kniberg's " "Scrum e XP dal libro delle trincee". Ne abbiamo già parlato in un thread diverso.

Il completamento della metà del tempo è un'enorme variazione rispetto alle stime. Per me, ciò significherebbe un rischio significativo che ciò che il tuo team ha effettivamente deviato da ciò che gli utenti si aspettavano all'inizio dello Sprint. Inoltre, uno Sprint dovrebbe anche fornire abbastanza funzionalità che è giunto il momento di ricevere un nuovo feedback dall'OP.

Quindi il rischio è solo quello di afferrare la roba dalla parte superiore della PB e di continuare a giocare perché quegli oggetti in cima alla PB sono obsoleti (sia nel contenuto che nella priorità) e che la tua squadra ha sbagliato qualcosa in l'ultimo Sprint e ti baserai solo su quegli errori senza ottenere feedback dal PO.

Direi che la soluzione più ragionevole è chiamare lo Sprint, tenere la tua consueta fine della recensione di Sprint, pianificare la riunione e la retrospettiva e iniziare il prossimo Sprint.

Per quanto riguarda la tabella di burndown, la domanda originale sembra mancare il senso di ciò che serve. È davvero solo uno strumento per determinare se hai un problema con i progressi durante lo Sprint. Con quello che è stato descritto, il grafico di burndown dovrebbe essere entrato in gioco in questa situazione circa al 2 ° o 3 ° giorno dello Sprint, quando avrebbe dimostrato che la squadra era molto, molto prima del previsto nei compiti di Sprint. Poi poni la domanda "Perché?", E stabilisci se le tue stime sono appena lontane o forse i programmatori interpretano male i compiti, o se qualcosa sta andando fuori dai binari in qualche modo.

Ma quando ignori il grafico di burndown e vai in crociera come se non succedesse nulla di strano, allora sembra che tu lo tratti semplicemente come un inutile artefatto che stai producendo perché il "libro" ti dice di farlo. Secondo me, se dovessi decidere di tirare fuori un po 'di roba dal PB e proseguire per la seconda settimana, inizia semplicemente un nuovo burndown per la seconda settimana (e poi puoi ignorare come hai fatto per la prima settimana).

Vorrei consultare il proprietario del prodotto su quale lavoro fare e aggiungerlo allo sprint corrente alla data in cui è stato introdotto il lavoro. È possibile tenere traccia del lavoro aggiunto sul grafico di masterizzazione. Non ho problemi con una tabella di masterizzazione che assomiglia un po 'alle montagne russe. Ciò avverrà comunque quando i membri di scrum stimano il tempo rimanente per le attività.