Come si determina la velocità quando lo sprint precedente era metà User Stories e Half Defects?

La velocità è X perché la velocità misura quanti punti della storia (= valore aziendale) hai consegnato nell'ultimo sprint. Ma hai un secondo valore disponibile: la capacità. La capacità è il numero di ore / giorni uomo disponibili per lo sprint. Quindi se ora raddoppi la capacità puoi presumere che la tua velocità aumenterà. Spetta alla squadra giudicare se raddoppiare la capacità raddoppierà la velocità prevista. Naturalmente non ogni aumento di capacità porterà ad un aumento della velocità. Ad esempio, l'aggiunta di membri della squadra non avrà sicuramente effetto immediato dell'aumento di velocità (il contrario è solitamente vero per pochi sprint).

Se la tua capacità cambia frequentemente per un numero elevato di ore / giorni uomo, ciò influirà sul valore medio della velocità e il suo significato per la previsione sarà molto peggiore.

Btw. Il 50% di spesa in termini di bug fixing dovrebbe sollevare alcune domande sul modo in cui gestisci la qualità del tuo prodotto = come crei la tua suite di test automatizzata.

Aggiungi il tempo speso per correggere i bug di una storia al tempo dedicato allo sviluppo della storia (perché in realtà il tempo totale che hai speso per sviluppare la storia include la correzione dei bug: la storia non era accettabile per il proprietario del prodotto in stato di buggy ). Ora che è un'indicazione della tua velocità.

A tutti i compiti completati dovrebbe essere assegnato un tipo di stima. Queste stime possono essere nel tempo, nelle storie degli utenti o in qualche altra unità.

Al termine dello sprint, saprai quali attività sono state completate e quali no. Anche se alcune delle attività dovessero risolvere i difetti, si considerano comunque attività completate.

Puoi utilizzare queste informazioni per raccogliere la tua pendenza. Da qui, sarai in grado di applicarlo a un grafico di burn-down e ottenere una percentuale su quando sarai a corto con il progetto a portata di mano.

Infine, i bug creati durante uno sprint dovrebbero essere risolti prima della fine dell'iterazione. Un'attività non dovrebbe essere considerata eseguita se ha avuto bug in sospeso in uno sprint.

Se i difetti rilevati non sono correlati a una storia attualmente attiva, la prioritizzazione e la stima dei difetti dovrebbero far parte della pianificazione sprint.

Prima della pianificazione, il team può assegnare punti ai difetti nello stesso modo in cui assegnano punti alle funzionalità, il che consentirà al proprietario del prodotto di stabilire la priorità dei difetti in relazione alle funzionalità. Il tempo necessario per indagare e risolvere i difetti dovrebbe essere definito come attività associate al difetto.

È molto importante che il proprietario del prodotto venga informato del livello di sforzo richiesto per risolvere ciascun difetto, in modo da avere un quadro chiaro di ciò che sta accadendo. Esiterei a permettere che un dibattito filosofico sulla definizione di "velocità" interferisca con questo.

Tuttavia, se stai tentando di dimostrare alla direzione che un alto tasso di difetti influisce sulla velocità di consegna delle funzionalità, puoi sempre mostrarlo tramite conteggio difetti o rapporto difetto / funzionalità.

Penso che sarebbe meglio che mostrare una velocità declinante senza spiegazione.