Gestione dei bug in Scrum

Ciao! Figurati, non è per niente una domanda stupida, anzi è un argomento molto discusso e per cui non è semplice trovare un equilibrio.

Scrum non dà alcuna indicazione precisa su come gestire i defect, ma sulla guida ufficiale viene detto chiaramente che tutto ciò che ha un impatto sul prodotto deve essere aggiunto al product backlog. Il problema però resta. Quanto è urgente il bug? Che impatto ha sul prodotto e sugli utenti? Deve essere risolto subito?

In linea di principio, ogni bug dovrebbe essere aggiunto al product backlog e priorizzato. Ma come già detto, e come spesso accade in Scrum… Dipende!

Il mio suggerimento di buon senso è di risolvere un defect il prima possibile. Se fattibile, durante l’iterazione in corso, se non impatta e non compromette lo Sprint Goal. Altrimenti, è una valutazione che il product owner deve effettuare in base a parametri di business. Per esempio: ha un "costo" maggiore ritardare la risoluzione del bug, oppure ha un "costo" maggiore rivedere lo scope dello sprint in corso?

Spero di non averti messo ulteriori dubbi

Saluti,

Franco

Nella mia vecchia azienda, oltre al normale backlog, avevamo una kanban board dedicata ai bug. Se il cliente trovava un bug lo gestivamo con kanban, così da lavorare sia sullo sprint che sui bug. Solo una parte del team lavorava a tempo pieno su kanban.

Magari anche questo potrebbe essere un approccio? Per noi funzionava e il cliente era contento!

Se funziona nel tuo contesto e il cliente è soddisfatto, perché no. Ma c’è il rischio che diventi una scorciatoia per aggiungere lavoro non pianificato allo sprint.

Solo una curiosità, perché così tanti bug da giustificare la creazione di un sub-team e di un processo a parte?

Una pessima qualità del software e la quasi inesistenza di pratiche di test automatizzati e deploy. Ogni volta che rilasciavamo incrociavamo le dita, roba da infarto!