Come calcolare il grafico di burndown di scrum quando i progetti si sovrappongono?

Quando un team SCRUM lavora su storie di più progetti, dovresti avere diversi grafici di burn-down:

• Un grafico che indica lo stato di avanzamento delle storie all'interno dello sprint corrente. Questo grafico viene aggiornato quotidianamente dal team per indicare come stanno procedendo verso lo sprint-obiettivo di quello sprint. Da dove provengono le storie sul grafico non dovrebbe essere importante per il grafico.
• Un grafico per progetto per tenere traccia di come il progetto sta progredendo verso la sua data di rilascio. Questo grafico è principalmente per i project manager per tenere traccia dell'avanzamento dei loro progetti e dovrebbe essere aggiornato solo quando una squadra fornisce un resoconto per quel progetto.

La misurazione della velocità è SCRUM che intende dare al team una misura per quanto costanti stimano la quantità di lavoro / complessità che possono gestire in uno sprint. Questo può funzionare solo se c'è un singolo golden standard da usare come riferimento per un'unità di lavoro / complessità.
Lo standard golden può (e lo sarà) differire tra i team, ma dovrebbe essere coerente all'interno di una squadra, anche se quella squadra lavora su storie di progetti diversi.

Il modo consigliato per stabilire un tale standard d'oro è quello di scegliere una storia di media difficoltà e dare 3 punti storia. Quindi valuti tutte le altre storie relative a quel gold standard.

I grafici di burndown sono usati per stimare la quantità di sforzi (punti) rimanenti per un rilascio. A volte, questo può essere proiettato per ottenere un'approssimazione approssimativa della data di rilascio in base alla consegna.

Se il tuo obiettivo è di tracciare esclusivamente i punti della storia (non la data di rilascio), la maggior parte degli strumenti ti consente di creare feature o sottogruppi all'interno di un progetto principale e ottenere separatamente i grafici del punto di storia per ciascuna caratteristica. Questo ti aiuta a tenere traccia del flusso di storie in ogni funzione.

Tuttavia, se si sta tentando di monitorare la consegna puntuale rispetto a una data di rilascio, il flusso di lavoro lo rende in qualche modo privo di significato. Considera che la tua squadra impiega un diverso numero di ore ogni settimana per ogni particolare progetto. Se non sai quanti sforzi puoi mettere per ogni settimana in futuro, come calcolerai anche quando tutte le attività finiranno?

Detto questo, ho alcuni suggerimenti. Puoi provare a "approssimare" una velocità standard per ogni singolo progetto. Modifica attivamente la priorità della tua squadra in modo che il team "nel suo insieme" produca velocità standard per progetto. Gli individui continuerebbero a variare secondo la loro esperienza in progetti specifici.

Lo faresti comunque per assicurarti che nessun progetto rimanga indietro. Basta formalizzare tale processo e quindi utilizzare questa velocità per tenere traccia delle metriche di puntualità.

I punti storia sono un valore relativo. Quanto lavoro è questa storia, rispetto ad un'altra? Una volta che hai dei riferimenti, dovresti essere in grado di stimare tutte le storie indipendentemente dal progetto per cui sono. Potrebbe essere che un'attività simile in un progetto sia sempre più lavoro che nell'altro - ma puoi comunque confrontare la quantità di lavoro con il tuo punto di riferimento.

La velocità nei punti di salvataggio per sprint dovrebbe quindi dipendere dal team, non dal progetto per cui lavorano.

Puoi quindi fare delle stime: Questo lavoro per il progetto 1 sarà fatto se il progetto 1 avrà la piena priorità. Se inseriamo queste storie dal progetto 2, questo sarà fatto.