Che cosa, se non altro, fare per i burndown a forma di arco?

Se stai ancora raggiungendo l'obiettivo, non lo vedo necessariamente come un problema. Hai incontrato il tuo obiettivo!

Parte del motivo per gli sprint / incrementi brevi è di mettere il team a fuoco: questo gruppo di lavoro dovrebbe essere completato entro la fine di questo sprint.

Se hai una lunga iterazione, la quantità di tempo si allunga come l'orizzonte: la scadenza non incombe mai finché non ci si trova proprio sotto di essa.

Inoltre, più estremità libere possono essere legate verso la fine dello sprint. Di nuovo, va bene. Il breve sprint di due settimane ha contribuito a risolvere queste cose prima che si accumulassero in una grande montagna di sei mesi di panico.

Se è coerente e prevedibile , non lo vedo come un problema.

A meno che tu rilevi che questo sta causando danni al tuo lavoro quantificabile , non ci sono problemi più urgenti da dedicare al tempo necessario? Se non ci sono, sono invidioso di te:)

Un modo per risolvere questo problema è creare storie più piccole e aggiungere realisticamente ricerche e approfondimenti attività di debug. Ciò che ha fatto il mio team è di abbattere le storie in modo che in genere non durino più di due o tre giorni.

Se crei storie piccole che possono essere "consumate" rapidamente e tieni le solite riunioni giornaliere, la tua squadra dovrebbe essere in grado di sbrigare rapidamente la quantità di lavoro rimanente nello sprint. Il grafico di burndown dovrebbe iniziare a riflettere anche questo stato. Naturalmente, non tutte le storie possono essere suddivise in questo modo, ma se la maggior parte delle storie sono piccole, probabilmente vedrai un grafico più lineare. Suppongo che gli sviluppatori chiuderanno le attività e amp; storie mentre concludono il lavoro. La mia squadra di solito fa questo prima della nostra mischia quotidiana - il maestro di mischia raccoglie piccole multe da quelli che dimenticano!

La tua situazione è tipica. Molti maestri di mischia stanno dando la caccia a un grande grafico di burn-down. Vedo un comportamento come un errore che porta a molti problemi in seguito. Burn down chart è un indicatore di allarme precoce.

Se sul tuo asse Y ci sono punti storia, la linea piatta è corretta. Le storie sono in genere più lunghe di 1 giorno e una volta completate, la linea sta andando verso il basso.

Se hai ore sul tuo asse Y, tale modello dice che la tua squadra non sta aggiornando il tempo rimanente o non è in grado di stimarla.

Anche in questo modo il team è ancora in grado di fornire, quindi significa che sono in grado di stimare correttamente la capacità dello sprint. E questo è ciò che conta davvero. Valutare in modo che siano in grado di realizzare ciò che hanno promesso.

Diversi pattern di burn down sono descritti in modo interessante in link