Ogni volta che ho lavorato nello sviluppo di software, c'era sempre un equivalente di un backlog, sempre un elenco di segnalazioni di bug e sempre qualcuno responsabile delle priorità (un equivalente di un PO), quindi la tua domanda, sebbene usi Scrum termini, è IMHO ben lungi dall'essere limitato a Scrum.
Una rapida ricerca su google per "scrum backlog bug" ha rivelato che alcuni team separano bug / problemi da storie di "nuova funzionalità", altri no. A volte vengono utilizzati i tracker dei problemi, a volte un Wiki, a volte tutto va direttamente nel backlog, ecc., E non c'è consenso "che sia meglio". Quindi la prima cosa che dovresti chiarire nella tua squadra come tu vuoi gestire questo, cosa vuole vedere il tuo team nel backlog e cosa no, e cosa fa il tuo team penso che funzionerà meglio per il tuo caso.
Se hai fatto l'esperienza che se a tutti è permesso di aggiungere qualcosa al backlog è un problema, probabilmente sarà meglio separare le storie degli utenti dai bug. I requisiti su come dovrebbe essere una buona segnalazione di bug sono probabilmente diversi dai requisiti su come dovrebbe essere una buona user story per una nuova funzione, il che potrebbe essere un altro motivo. Ciononostante, entrambi finiranno nelle attività per gli sviluppatori, il che potrebbe essere un motivo per mantenerli in un unico posto.
Tuttavia, per la maggior parte dei prodotti ha senso quando le segnalazioni di bug possono essere fornite da chiunque (utenti, tester, sviluppatori, addetti al marketing, chiunque si accorga di un potenziale problema). "Le nuove funzionalità" dovrebbero probabilmente essere discusse con l'ordine di acquisto come parte del processo quando si aggiungono al backlog. Il tuo PO dovrebbe decidere se vuole inserire le storie da solo per fare un po 'di lavoro editoriale in anticipo, o se qualcuno può mettere le storie per l'arretrato e poi fa il lavoro editoriale. Ma per i bug, specialmente quelli che sembrano gravi per il reporter, non dovrebbero esserci discussioni necessarie per aggiungerli al tracker dei problemi, o al documento di backlog o buglist, o ovunque li tenga. "Nessuna discussione" non significa mettere il bug report ovunque in silenzio, anzi. Quando viene aggiunta una segnalazione di bug e il giornalista pensa che probabilmente non è minore, l'OP (o chiunque sia responsabile) deve essere informato.
Come nota finale: per prendere la decisione giusta per il tuo team su come gestirlo, fa davvero la differenza rispetto alle dimensioni del tuo prodotto, quante persone segnalano bug e nuove storie, e se ne ottieni una, ma rapporto a settimana, una dozzina o diverse centinaia.