come funziona il burndown?

Risposte a questa discussione

Permalink Risposto da Pierluigi Pugliese su 16 dicembre 2010 a 0:46

Un paio di suggerimenti:

 

1. Il grafico va aggiornato ogni giorno, dopo lo standup. Non è necessario che lo aggiorni lo ScrumMaster, anzi è bene che lo faccia qualcun'altro nel team, in modo che prendano la responsabilità dei loro artefatti

1.1 Se le storie sono grandi tenete traccia dei vari task componenti la storia e delle ore mancanti alla fine di ogni task, in modo da monitorare il progresso. Attenzione: è un tracking di quanto manca, non una giustificazione di come ogni sviluppatore ha utilizzato il suo tempo nella giornata passata. Controllando le ore "passate" si potrebbe instaurare una cultura di difesa e di micromanagement che fa a pugni con la auto-organizzazione del team.

2. Una storia non finita vale 0 punti, finita vale il numero di punti stimati. Se non è finita ed integrata non esiste. Brutale, ma efficace. L'unica eccezione che ammetto è per le storie non finite alla fine dello sprint, dove considero la storia parzialmente sviluppata nel calcolo della velocità, ma non per definire la percentuale di product backlog bruciato. (voglio avere una velocità che sia più veritiera possibile per decidere quanto pianificare nel prossimo sprint)

3. Quanto è lungo lo sprint? Se sono 2 settimane o più, le storie sono, a mio parere, troppo grandi e dovresti cercare di spezzarle/farle spezzare, in modo da avere un feedback più granulare dell'andamento

3.1 Attenzione però a non spezzare le storie in design/sviluppo/test/..., ma di spezzare la funzionalità da sviluppare in modo che ogni storia sia comunque completa fino al test

 

In bocca al lupo!

Pierluigi

• ▶ Rispondi

Permalink Risposto da Marco D'Amico su 16 dicembre 2010 a 10:40

Ciao Pierluigi, grazie per tutti i suggerimenti.

@3: Lo Sprint è lungo 13 giorni lavorativi.

Avendo un team di 7 persone (2 designer + 5 sviluppatori):

• uno Sprint di 3 settimane (15gg lavorativi) quanti Story Points può contenere?
• e uno Sprint di 2 settimane (10gg lavorativi) quanti Story Points può contenere?

Ti ringrazio moltissimo.

Ciao :-)

• ▶ Rispondi

Permalink Risposto da Pierluigi Pugliese su 16 dicembre 2010 a 12:58

La domanda reale è quanto sono grandi le storie: in generale più sono piccole meglio è. La traduzione in story point è dipendente dal team e non è particolarmente rilevante. Anzi, probabilmente riscontrerai che il valore di uno story point cambierà nel corso dei prossimi sprints.

 

Nel tuo caso, a meno che le storie siano tutte di 1-2 story points (cosa rara al primo sprint) hai poche storie e grandi - non in termini di SP ma in termini di lead time per completarle: 32 SP in 13 giorni sono ~2 SP/giorno. Per 9 persone non mi sembra dare una granularità sufficiente a fare un tracking. Ma lo sperimenterete sul campo e vedrete se cambiare la definizione durante la retrospettiva.

 

• ▶ Rispondi

Permalink Risposto da Andrea Maietta su 20 dicembre 2010 a 9:49

Non esistono story points aggiornati: se una storia è stimata cinque, quei cinque punti rimangono interamente tra le cose da fare finchè la storia non è finita ("finita finita" per usare la terminologia Scrum): non puoi dire "questa è una storia da cinque, ma ne ho fatta più di metà quindi mi mancano solo due punti per finire. In Scrum non esiste il concetto di "finito al 90%". Anche perché sappiamo che è nel 10% che manca che si nascondono tutti i dettagli più maledetti :-)

Invece se nel corso dell'iterazione emergono altre storie che devono essere realizzate per il successo dello sprint queste devono essere inserite nel burndown. Eventualmente il PO deciderà cosa sfrondare.

Lavorare in questo modo è utile anche perché ti rendi conto se hai troppe storie di dimensioni eccessive (il grafico se ne sta piatto per un sacco di tempo poi crolla di colpo), il che è un rischio.

Se non riesci a spezzare le storie forse invece ti conviene tracciare il tempo che manca per ogni task. Come dice giustamente Pierluigi non si traccia quanto tempo si è impiegato, perché non è utile per la gestione dello sprint (al limite può essere utile per migliorare la nostra capacità di stimare). L'importante è che anche qua si aggiorni effettivamente il tempo che manca, non basta dire "è un task di quattro ore, ho lavorato per due ore quindi ne mancano solo due". Potrebbero mancare dieci minuti ma anche altre dodici ore, e il dato va indicato correttamente.

Nel daily scrum tradizionalmente ci si dice "cosa ho fatto ieri", "cosa farò oggi", "quali impedimenti ho trovato". Per l'aggiornamento del burndown si può usare una persona che ha il compito, magari alla fine della giornata, di raccogliere le informazioni dai membri del team, oppure i membri stessi possono dare le informazioni necessarie. Sempre come dice Pierluigi, meglio se non lo fa lo Scrum Master.

Difficile dire quanti story points possono stare in uno sprint, anche perchè i tuoi non sono i miei, anzi per ogni team sono diversi.

• ▶ Rispondi

Permalink Risposto da Fabio Armani su 11 Febbraio 2011 a 18:41

Ciao Marco

per quanto riguarda il burn down ed i suoi aggiornamenti esistono essenzialmente due scuole.

 

La prima (quella storica) considera che nel Burn Down vengano conteggiate le ore dei task e non gli story point dei PBI (Product Backlog Item). In questo caso è semplice, ognuno prima dello stand up aggiorna il propri task in termini di remaining hours (bada bene non il lavoro fatto ma una nuova stima delle ore "ideali".

 

La seconda (direi preferita e più moderna) si basa solo sui PBi ovvero sulle user story. In questo caso non c'è avanzamento fichè le storie non sono chiuse ovvero DONE DONE!

 

spero di esserti stato utile.

un link: http://www.open-ware.org/ita/glossary/burndown-chart.htm

fA

• ▶ Rispondi