Siempre que trabajé en el desarrollo de software, siempre hubo un equivalente de una cartera de pedidos, siempre una lista de informes de errores y siempre alguien responsable de las prioridades (un equivalente de un PO), por lo que su pregunta, aunque utiliza los términos de Scrum, es En mi humilde opinión, lejos de ser restringido a Scrum.
Una búsqueda rápida en Google de "errores de registro de scrum" reveló que algunos equipos separan los errores / problemas de las historias de "nuevas características", otros no. A veces se utilizan rastreadores de problemas, a veces un Wiki, a veces todo va directamente a la cartera de pedidos, etc., y no hay consenso "cuál es mejor". Así que lo primero que se debe aclarar en su equipo de cómo se quiere manejar esto, lo que hace su equipo quiere ver en el atraso y lo que no, y lo que hace su equipo piensa que funciona mejor para su caso.
Si crees que si a todo el mundo se le permite agregar algo a la lista de tareas pendientes, probablemente sea mejor separar las historias de los usuarios de los errores. Los requisitos sobre cómo debería ser un buen informe de errores probablemente sean diferentes de los requisitos sobre cómo debería ser una buena historia de usuario para una nueva función, lo que también podría ser otra razón. Sin embargo, ambos terminarán en tareas para los desarrolladores, lo que podría ser una razón para mantenerlos en un solo lugar.
Sin embargo, para la mayoría de los productos tiene sentido cuando cualquier persona puede proporcionar informes de errores (usuarios, evaluadores, desarrolladores, personal de marketing, cualquiera que note un problema potencial). Las "nuevas características" probablemente deberían discutirse con la OP como parte del proceso al agregarlas a la cartera de pedidos. Su OP debe decidir si quiere poner las historias allí solo para hacer un trabajo editorial de antemano, o si alguien puede poner las historias en el trabajo atrasado y luego hace el trabajo editorial. Pero para los errores, especialmente los que parecen ser severos para el reportero, no debería haber ninguna discusión necesaria para agregarlos al rastreador de problemas, o el registro de reserva o el documento de la lista de errores, o donde sea que los guarde. "Sin discusión" no significa colocar el informe de error en ningún lugar en silencio, sino todo lo contrario. Cuando se agrega un informe de error,
Como nota final: para tomar la decisión correcta para su equipo sobre cómo manejar esto, hace una gran diferencia qué tamaño tiene su producto, cuántas personas van a reportar errores e historias nuevas, y si obtiene uno, pero informe por semana , una docena o varios cientos.