Questo è 3 compiti, non uno.

Potrebbe essere una caratteristica / storia, ma sono tre compiti. Una singola attività può essere completata da una singola persona in un tempo limitato.

TL; DR

Stai utilizzando il burn-down in modo errato in diversi modi. Compiti e storie sono fatti o non fatti; tentando di tenere traccia delle deviazioni dalle stime di pianificazione basate sul tempo nel tuo burn-down, stai effettivamente rivalutando il tuo programma piuttosto che stimando il lavoro-prodotto rimanente.

In Scrum, dovresti misurare i progressi verso lo Sprint Goal piuttosto che misurare il time-box dello Sprint. Ciò mantiene l'attenzione sulla capacità del team e sulla consegna delle funzionalità piuttosto che su aggiustamenti di programmazione continui.

Attività rispetto a storie

Stai confondendo compiti e storie. Le storie comprendono tutti i compiti richiesti per completare la storia secondo la "definizione di fatto" della tua squadra. La storia è considerata 100% incompleta a meno che tutti i suoi compiti siano completi. In Scrum, le storie sono sempre stimate in qualche modo; più frequentemente, sono stimati in punti storia.

I compiti sono i passi o le tappe fondamentali necessari per completare la storia. Sebbene ogni attività possa avere dipendenze e prerequisiti, puoi certamente dire che la revisione del codice è completa o meno, indipendentemente dalle altre attività.

Burn-Giù

In Scrum, il grafico di burn-down mostra la quantità di lavoro rimanente per lo sprint o il progetto. I veri grafici di burn-down spesso hanno altipiani; in alcuni casi, il grafico può persino aumentare. Ad esempio, in uno sprint di una settimana con due storie del valore di 3 e 5 punti, i tuoi punti dati potrebbero essere qualcosa del genere:

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

In questo scenario idealistico, inizi con 8 punti storia. La storia di 3 punti è stata completata martedì pomeriggio, mentre la storia di 5 punti non è stata completata fino a venerdì. I punti della trama non vengono detratti dal burn-down finché la storia non ha soddisfatto la definizione di fatto. Se utilizzi le ore ideali invece dei punti storia, l'unica cosa che cambia è la tua scala.

Tempo-Boxing

La pratica generalmente accettata è quella di garantire che le tue attività vengano scomposte in blocchi di dimensioni da morso tra 1/2 giorno e 2 giorni. La varianza di più di un giorno dovrebbe essere evidente dagli attacchi giornalieri o dallo Sprint Backlog; non ci dovrebbe essere bisogno di eseguire un formale status pull.

È anche possibile eseguire analisi statistiche sul grafico di burn-down per determinare se lo sprint è in trend in modo corretto. Piccole deviazioni o altipiani sono normali, ma se nessuno sta sollevando alcun bloccante negli stand-up giornalieri ma il burn-down sembra bloccato, questo è generalmente un segno che lo Sprint Backlog è stato erroneamente stimato o che esiste un "lavoro invisibile" che deve essere reso esplicito nel tuo processo.

Puoi definire l'attività di sviluppo come "completata" prima che il QA faccia la loro parte? Puoi definire la revisione del codice come "fatta" prima che lo sviluppo sia fatto? Il QA può essere "fatto" se lo sviluppo e la revisione del codice non lo sono?

Direi che dovresti aggregare i tre elementi in una singola attività e le tre persone dovrebbero collaborare su di essa.

Scrum NON dice che ogni elemento è responsabilità di un membro del team. Al contrario, gli articoli del registro Sprint sono a carico del TEAM. Se ci vogliono tre persone per eseguire un'attività, allora è quello che serve.

Non importa. Fintanto che è relativamente coerente tra le storie, il grafico di burndown funzionerà comunque in entrambi i casi. Usa il modo più naturale per la tua squadra di segnalare.

La mia squadra fa una specie di ibrido, anche se non con un accordo formale. Abbiamo messo 16 ore se pensiamo che un compito richiederà una persona due giorni, ma se due persone finiscono per lavorarci insieme, non lo cambiamo.

Dopo la stima iniziale, per la nostra squadra diventa informalmente più completa della percentuale di un'ora rimanente. Se inizialmente avessimo pensato che ci sarebbero voluti due giorni, ma dopo un giorno, pensiamo che sia solo il 25% completo, prendiamo 4 delle 16 ore di pausa originali. Rimangono 12 ore in cui tecnicamente stimiamo 24, perché probabilmente dedurremo 4 ore per i restanti 3 giorni.

Questo mi ha dato fastidio come scrum master all'inizio, ma strano a quanto pare, è un modo molto naturale per fornire stime, perché gli sviluppatori odiano davvero aggiungere ore a una stima. Tutto ha una media per rendere il burndown ancora utile, e questo è ciò che è importante.

Il tempo rimanente per l'attività non conta molto: non è possibile fornire nulla finché non viene completata l'intera storia.

Se desideri tenere traccia di quanto tempo è rimasto in una storia (in generale) facendo in modo che le persone riempiano il tempo rimanente per le attività, quindi suddividi i compiti a persona.

Detto questo:

• Grandi attività potrebbero essere un'indicazione che le tue storie sono troppo grandi. In questo caso, la soluzione migliore consiste nel ridurre l'ambito e la dimensione delle storie e, se la si riduce, è sufficiente il tempo rimanente di tracciamento per le attività (sono fatte o meno) somma delle stime sulle attività non eseguite è abbastanza granulare).
• SCRUM incoraggia tutti a raccogliere ciò che deve fare. Se stai assegnando compiti a persone (al contrario dei ruoli), allora ti stai potenzialmente impedendo di pubblicare una storia, anche se lo sviluppatore non sta facendo nulla - perché il QA è colto da un collo di bottiglia.

Dividi l'attività in più attività e inseriscile come attività in cui ciascuna di esse è gestita da una persona diversa.

Attività originale: correggi qualcosa

Nuovi compiti: (figlio del genitore dell'attività originale)

• Dev A - Correzione del problema
• Dev B - Aiutare Dev A a risolvere il problema (cioè la programmazione della coppia, la revisione del codice)
• Dev A - dev testare la correzione utilizzando il set di dati X
• Dev B - dev testare la correzione utilizzando il set di dati Y