Scrum bruciare i grafici, possono andare negativo? [chiuso]

Question

Io lavoro su un piccolo team di sviluppo Agile, che è parte di una grande, non agile pensiero Corporation. Attualmente, si pratica Scrum e di tanto in tanto, superiamo il nostro impegno sprint.

La mia domanda è: come si fa a gestire bruciare classifiche quando si è superato il vostro impegno sprint? Mi vengono in mente due opzioni:

• estendere l'asse y nella direzione negativa e tenere conto alla rovescia
• Aggiungi più schede / stories / lavoro e hanno la incendiare aumento del valore di tale importo, bruciando quando che il lavoro è finito.

La soluzione definitiva per la mia squadra è quella che è chiaro per il business e aggiunge valore reale per gli sviluppatori. Finora, nessuna di queste soluzioni ha funzionato alla perfezione.

Answer 1

A mio parere, i grafici burndown non possono andare negativo. Se hai finito con il vostro lavoro si sia continuare a seduti nel vostro sedie non fare nulla che significa che il burndown rimarrà a zero.

Se davvero fare qualcosa, allora questo dovrebbe essere aggiunto al tuo elenco delle attività, il che significa che il burndown andrà su e poi giù di nuovo, quando hai finito con compiti aggiunti al carico di lavoro del vostro sprint.

Una volata in cui il carico di lavoro originale è stato completato prima della fine del sprint dovrebbe mostrare un po 'di picco, quando sono stati nuovamente aggiunti nuovi compiti (sia compiti singoli, ad esempio correzioni di bug o qualsiasi altra cosa, o di una o più nuove storie di utenti), una volta che è diventato chiaro che non c'è spazio per altri.

Tuttavia, se questo accade di frequente con la tua squadra ti sembra di essere costantemente sottovalutare la tua velocità e dovrebbe iniziare impegnarsi in più attività fin dall'inizio. Non sto dicendo che è una brutta cosa per essere in grado di finire presto e prendere su più compiti, ma se questo accade in un sacco di sprint è un segno che la squadra sta undercommitting fin dall'inizio, per caso o per fare assolutamente sicuri che non c'è modo verranno a mancare la volata.

Se va bene con il proprietario del prodotto, così sia. Se fossi il proprietario del prodotto e vorrei vedere una squadra sempre finire presto avrei cercato di convincerli a impegnarsi per più attività fin dall'inizio. Questo potrebbe sembrare un po 'più dura di quanto è destinato a suonare.

Answer 2

Burndowns mostrano portata rimanendo all'interno di un impegno. Se si aggiunge qualcosa al vostro impegno perché siete over-consegna, lo si aggiunge al numero che si sta registrando nel grafico. Come risultato, una squadra che è over-consegna avrà un burndown che si dirige verso lo zero e poi si libra là fino alla fine del timebox sulle carte nautiche.

Per mostrare ciò che si sta realmente Consegnare, prendere in considerazione una bruciare o diagramma di flusso cumulativo, invece.

Modifica

• Burn-bassi mostrano lavoro rimanente per completare "qualcosa" (uno sprint, un comunicato, un MMF / "epico", ecc.)
• Burn-up mostrano accumulo di "qualcosa" (valore di business guadagnati, di superare la complessità, ecc.)
• diagrammi di flusso cumulativi mostrano entrambi + dare informazioni sulla qualità del vostro processo

Answer 3

Quando aggiungiamo altri elementi alla volata, aggiorniamo il stima del lavoro rimanente per riflettere che sul grafico sprint burndown:

alt text http://www.movingsummit.co.uk/images/burndown_chart .JPG

Ma, come sottolineato in altre risposte, questo dimostra che il stima del lavoro rimanente cambiato, non la ragione (abbiamo appena ri-stimare il lavoro o ha fatto aggiungiamo lavoro?) E non l'accumulo di lavoro svolto. Questo potrebbe non essere un problema però.

Per rappresentare l'accumulo di lavoro svolto, un grafico burnup è più appropriato (usiamo un grafico burnup a livello di rilascio). Un burnup contro il carico di lavoro permette di rappresentare lo stato di avanzamento del lavoro svolto e anche un aumento o una diminuzione del fabbisogno (e come questo influenza la previsione di completamento):

alt text http://www.movingsummit.co.uk/images/burnup_chart .JPG

Answer 4

L'estensione dell'asse Y rende veramente chiaro a tutti che si sta andando al di là l'obiettivo sprint. Di solito non è un grosso problema perché non si va molto oltre.

Se diventa un evento regolare o se si va oltre da una quantità significativa c'è qualcosa di sbagliato con il processo di stima. Forse siete eccessivamente cauto nel trattare con il lato "non agili" del business. Cercare di portare a tutti per il lungo viaggio.

Answer 5

Y Estensione del grafico burndown sotto zero è ben consolidata prassi monitorare stampa progresso.

Esempio grafico rilascio burndown

In un'immagine collegata potete vedere rilascia burn down chart - tutto ciò che viene aggiunto a rilasciare portata va oltre lo zero.

Non consiglierei facendo esattamente la stessa cosa di sprint burn down chart. Si dovrebbe sufficiente aggiungere un nuovo lavoro al restante lavoro e, ovviamente, il vostro burndown andrà per un po '. Se stai usando lavagna per presentare il grafico burndown sprint è una buona idea per etichettare il luogo nel momento in cui si è aggiunto nuove storie / esigenze con una corretta commento. In questo modo sarà perfettamente visibile ciò che è successo e perché il tuo burndown salì.

Answer 6

Se si sta andando persistentemente negativo con il vostro bruciare giù, che indicherebbe che si sono costantemente sopra la stima, finendo in tal modo il vostro lavoro "troppo presto". Per risolvere questo problema, iniziare a moltiplicare la stima di un fattore inferiore a 1 (cioè 0,75, 3/4) (non ricordo il termine corretto per questo - è "scala"?). Fare questo per uno sprint o tre, vedere come influisce il risultato, si può prendere un paio di iterazioni per ottenere il fattore giusta per ogni sviluppatore. Questo significa che sarà in grado di adattarsi più all'interno la volata regolare e non dovrebbe finire presto.

Answer 7

Mi permetto di dissentire qui :-) Provate a prendere in considerazione il seguente scenario: La squadra inizia a lavorare su una storia e rendersi conto che una certa quantità di lavoro non è stato pianificato, e ora aggiungere attività per completare quel lavoro. Il burndown sale, ma non esattamente per una buona ragione, in questo caso, non è il cambiamento campo di applicazione, ma è "la stima sbagliato", che dal punto di vista una squadra non fa alcuna differenza, come il messaggio è ancora: "questa è la quantità di lavoro che deve essere completato".

E il proprietario del prodotto? Quanto si vuole comunicare che si è consegnato oltre-? Quanto è importante per la squadra di distinguere i due casi, e li usa alla retrospettiva di analizzare come migliorare le stime la prossima volta, o commettono a più fin dall'inizio? Un approccio simile è stato utilizzato per definire il grafico burndown alternativa ( http://www.mountaingoatsoftware.com / mischia / alt-releaseburndown ), in modo da ri-basare il grafico e la combustione di più verso il basso, mostrano chiaramente un aumento della portata, e bruciando potrebbe essere il team ha scoperto nuovi compiti, mentre di iniziare a lavorare su una storia da qualche parte in volata ; -)

Ciao
ANdreaT