Come si disegna il grafico di burndown di sprint?

Question

Come si disegna il grafico di burndown di sprint?

#1 da (3 voti)
#2 da (0 voti)

4

Nella mia azienda, ci sono 3 diversi team di sviluppo, mischia appena iniziata. Principalmente seguono lo stesso percorso nel fare scrum, ma quando si tratta di sprint burndown chart, l'atto è diverso.

Una squadra, punti storia riuniti (con punti stimati in essi), li ha suddivisi in compiti e punti stimati per loro, cioè una storia di 10 punti può avere 3 compiti con 4, 1 e 5 punti stimati per loro rispettivamente. Quando hanno completato un'attività, hanno aggiornato rispettivamente il grafico di burndown. Il risultato era una tabella di burndown relativamente liscia, ma in caso di storie fallite era in qualche modo ingannevole; Ha mostrato progressi che non sono stati effettivamente realizzati per l'utente finale.

Sul lato opposto, altri team non hanno valutato i punti per le attività e hanno appena aggiornato il grafico di burndown quando una storia è stata completata. Il risultato è stato un diagramma a forma di scala: per alcuni giorni la squadra non ha fatto progressi e improvvisamente ha fatto un grande passo avanti.

La domanda è, qual è il modo giusto per rendere il grafico di burndown e quale approccio era più vicino ad esso?

agile scrum burndown

posta Mehraban 09.05.2015 - 08:03

fonte

2 risposte

Leggi altre domande sui tag agile scrum burndown

Miglioramento del metodo di bisezione o dell'algoritmo alternativo per la determinazione efficiente della dimensione del carattere del testo per adattarsi a una casella Che cosa è un'applicazione con vincoli di latenza e legata alla memoria in HPC?

score 3 · Answer 1

Chi è il pubblico per il grafico di burndown?

Il secondo metodo, in cui prendi credito dopo il completamento di una storia, è più in linea con le idee dietro Scrum. Qui ci sono diverse domande sull'ingegneria del software su come gestire storie incomplete ( 1 , 2 , 3 , 4 ). Una storia, non un'attività, rappresenta qualcosa di valore per l'utente. Se fai un passo indietro e considera lo sprint come una raccolta di storie e l'impegno a fornire una certa quantità di funzionalità, mostrare il grafico di burndown come indica il completamento di tali storie è utile al proprietario del prodotto e all'utente per mostrare quanto vicino devi rispettare tali impegni.

Nel primo metodo, in cui prendi credito dopo il completamento di un'attività, sembra essere più utile per uso interno, specialmente lo Scrum Master e il team di progetto. Queste sono le persone che pensano in termini di compiti e possono utilizzare le informazioni in questa vista come feedback per migliorare la stima e la pianificazione degli sprint.

Considera di utilizzare l'approccio giusto per il pubblico. Se non sei sicuro, chiedi a loro e discuterne. Sebbene derivi dagli approcci lean, elimina gli sprechi. Produci i manufatti e hai le cerimonie di cui hai bisogno per essere efficace e lavora in gruppo con gli altri stakeholder per decidere quali sono questi artefatti e cerimonie.

score 0 · Answer 2

Personalmente preferisco la prima. Ti dà un senso migliore di progresso e il "lavoro" fatto. Inoltre, molte volte la divisione in "User story" è alquanto arbitraria. Preferisco vedere quanto lavoro è stato programmato nello sprint attuale e quanto è stato effettivamente fatto.

Ma non importa. Ogni squadra dovrebbe scegliere ciò che le offre meglio. Questa è una delle idee fondamentali dietro l'agilità: il team trova il modo migliore per misurare e gestire se stesso.

Posso anche vedere la motivazione dietro la seconda strada. Si preoccupano meno del lavoro svolto e si preoccupano di più su quanto funzionalità e funzionalità hanno completato per gli utenti. Questo sembra più appropriato per storie brevi e semplici e per un progetto semplice dal punto di vista tecnico.