Mischia sopravvalutazione e ripianificazione

Siamo nel mezzo del nostro primo Sprint e qualcosa ci appare all'alba: abbiamo sopravvalutato!

Avevamo programmato 114 ore ideali per questa iterazione di 2 settimane e alla fine della prima settimana abbiamo terminato l'intero Sprint. Cosa facciamo adesso? Il "libro" dice che dovremmo, e otterremo, i prossimi articoli ad alta priorità dal backlog. Tuttavia, come possiamo aggiungerli al grafico di burn down? Lo riscriviamo per rendere conto di quelle storie come se fossero lì dall'inizio? O semplicemente aggiungi le loro stime all'asse y nel giorno in cui iniziamo a lavorarci (mostrando un salto di 90 °)?

Qualsiasi feedback è il benvenuto!

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

Le storie dei nuovi utenti non erano allo sprint all'inizio, quindi sembra un po 'complicato fingere di esserlo. Aggiungendoli nel grafico di burndown in questo momento, stai dimostrando con precisione che l'attuale livello di stima è ancora in qualche modo nelle sue fasi evolutive preliminari.

Questo è un bene per te e per il proprietario del tuo prodotto. Mostra e mostrerà come l'utilizzo di questo sistema di gestione dei progetti ti consentirà di diventare stimatori migliori.

Sarai in grado di vedere fin dall'inizio che stavi sopravvalutando, quindi sottostimando, quindi sopravvalutandone un po 'di più ma leggermente meno ... e alla fine vedrai i miglioramenti nella stima mentre procedi.

Penso che stimare le storie degli utenti sia una delle parti più difficili di uno sprint e solo una volta che il tuo team imparerà a evolversi insieme diventeranno sempre più efficienti nel processo. È bene averlo dimostrato attraverso gli strumenti che stai utilizzando, come il grafico di burndown.

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

Dalla guida ufficiale Scrum :

Gli Sprint possono essere annullati prima che la casella del tempo Sprint sia terminata. Solo il Product Owner ha l'autorità di annullare lo Sprint, sebbene possa farlo sotto l'influenza degli stakeholder, del Team o di ScrumMaster.

Poiché la pianificazione dello sprint dovrebbe essere effettuata nell'ambito di una discussione con il proprietario del prodotto, lo scrum master e il team, sarebbe controproducente scegliere semplicemente le storie degli utenti successivi.

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

È possibile aggiungere un grafico bruciato . 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 è introdurre uno scostamento sull'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 che fossero lì fin dall'inizio (che è molto più facile da usare grafici di burndown basati su CGI).

E potresti inventare il tuo.

La cosa più importante è discuterne tra team, mischia e proprietario del prodotto per raggiungere un accordo su ciò che si desidera fare in questa situazione. Non esiste un modo assolutamente fisso per fare qualsiasi cosa in mischia se non le regole di base. Scrum è pensato per evolversi nel tempo per soddisfare al meglio le esigenze del tuo ambiente.

Vorrei suddividere il problema del PO in tre domande distinte:

1. Continuare o annullare lo sprint?
2. Cosa fare nella settimana rimanente se lo sprint continua?
3. Come pianificare il prossimo sprint?

I grafici di burndown e burn-up menzionati in altre domande, sebbene utili, sono secondari rispetto al PO "cosa facciamo ora?"

Continua o annulla : sono qui con Pierre, è opportuno annullare questo sprint e iniziare subito a pianificare il prossimo. La cancellazione dello 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: limitare 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 finito alla fine dello sprint.

Come pianificare il prossimo : le opzioni qui sono provare la stima delle dimensioni relative o usare l'equivalenza storia-punto-persona-giorno e il fattore di messa a fuoco come approssimazione come descritto nel libro "Scrum and XP from the Trenches" di Henrik Kniberg. Ne abbiamo già discusso in un'altra discussione.

Essere completati in metà tempo è una grande variazione rispetto alle stime. Per me, ciò indicherebbe un rischio significativo che ciò che il tuo team ha effettivamente deviato da ciò che gli utenti si aspettavano all'inizio dello Sprint. Inoltre, si suppone che uno Sprint fornisca abbastanza funzionalità che è ora tempo di ricevere un nuovo feedback dall'OP.

Quindi il rischio di afferrare cose dalla parte superiore del PB e continuare è che quelle voci nella parte superiore del PB sono obsolete (sia nel contenuto che nella priorità) e che il tuo Team ha sbagliato qualcosa nell'ultimo Sprint e ti baserai su quegli errori senza ricevere feedback dall'OP.

Direi che il modo più ragionevole di agire è chiamare lo Sprint fatto, tenere la tua solita fine dello Sprint review, pianificare riunioni e retrospettive e iniziare il prossimo Sprint.

Per quanto riguarda le cose del grafico di burndown, la domanda originale sembra mancare il punto a cosa serve. È davvero solo uno strumento per determinare se stai riscontrando problemi con i progressi durante lo Sprint. Con quanto descritto, la tabella di burndown avrebbe dovuto entrare in gioco in questa situazione all'incirca nei giorni 2 o 3 dello Sprint, quando avrebbe dimostrato che la squadra era molto più avanti del programma sui compiti dello Sprint. Quindi fai la domanda "Perché?" E stabilisci se le tue stime erano appena fuori strada o forse i programmatori interpretano male le attività o se qualcosa sta andando fuori dai binari in qualche modo.

Ma quando ignori il grafico di burndown e vai avanti come se non ci fosse nulla di strano, sembra che tu lo stia trattando come un manufatto inutile che stai producendo perché il "libro" ti dice. Secondo me, se dovessi decidere di estrarre ancora un po 'di roba dalla parte superiore del PB e proseguire per la seconda settimana, allora inizia un nuovo burndown per la seconda settimana (e quindi puoi ignorare come hai fatto per quello la prima settimana).

Vorrei consultare il proprietario del prodotto su quale lavoro fare e aggiungerlo allo sprint corrente alla data in cui il lavoro è stato portato. Si può tracciare il lavoro aggiunto sulla tabella di burn down. Non ho problemi con una carta bruciata che assomigli un po 'alle montagne russe. Ciò accadrà comunque quando i membri della mischia stimano il tempo rimanente per le attività.