Assicurati di definire chiaramente al team che cosa sia un "bug" (/ errore / problema / difetto) e che cosa non lo è. Ad esempio, un bug potrebbe:
-
BE Una deviazione nel comportamento / aspetto di una funzione / storia precedentemente completata una volta distribuita alla produzione.
-
NON ESSERE Qualcosa che un proprietario di un prodotto, stakeholder o utente non gradisce o un suggerimento per un cambiamento di comportamento.
Questo è piuttosto critico in quanto si vuole minimizzare i bug nel backlog dato che di solito non aggiungono nuovo valore al prodotto (il valore avrebbe dovuto essere aggiunto quando la funzionalità priva di errori era stata completata inizialmente).
Quindi dato il nostro "bug" sopra:
- Ottieni una lista di bug tracking / backlog visibile da qualche parte in modo che il proprietario del prodotto possa dare la priorità a lui e al team e lavorare da esso. Utilizza una lavagna, pubblica i suoi o alcuni software come Trello .
- Forse un membro o un membro di un team tecnico senior può essere responsabile della valutazione di ogni nuovo bug che si presenta alla lista mentre accade. Dovrebbero attribuire un punteggio di gravità a ciascuno (punto colorato appiccicoso, tag in Trello) in modo che il proprietario del prodotto possa prendere una decisione informata sulla sua priorità in base all'impatto sul prodotto.
- Ogni settimana / sprint / ciclo, impegnarsi in un numero fisso di bug dall'elenco. Rendi il prodotto proprietario, scrum master, capo tecnico o manager del team applica questo rutual.
- Assicurati che il team o coloro che lavorano su detti bug abbiano tempo e spazio sufficienti per "squash" (risolverli).