¿A quién se le debe permitir agregar historias a la cartera de productos?

¿Cuál es la mejor práctica para evitar que el trabajo atrasado se convierta en un desastre, pero también para mantener la productividad del desarrollador?

¿A quién debemos permitir agregar historias a la cartera de productos? ¿Y cómo se asegura de que estas historias cumplan ciertos requisitos?

Por ejemplo, encuentro algunos pequeños errores de CSS durante el desarrollo de la Característica X. ¿Debería entonces, como desarrollador, permitirme agregar una historia que describa los errores al final del trabajo atrasado? ¿O debería discutirlo con el propietario del producto?

Hacer que todas las ideas / errores pasen por el propietario del producto parece un posible cuello de botella.

El enfoque habitual es que cualquiera puede agregar historias al trabajo atrasado. El propietario del producto los prioriza y el equipo los estima. Los problemas de calidad de la historia generalmente se solucionan de una forma u otra en la planificación de reuniones o retrospectivas.

Eso significa que el propietario del producto no es un cuello de botella siempre que esté satisfecho con las prioridades que está asignando. De lo contrario, haga su caso.

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.

Permitimos publicar errores en la parte inferior de la cartera de productos para todos en el equipo. El elemento debe corresponder a ciertas reglas (p. Ej., Condiciones para la reproducción, cuál es el comportamiento correcto, etc.). Sin embargo, se agregan nuevas características a la lista separada 'Ideas', de las cuales el PO las extrae en el Backlog (y obviamente las convierte en un PBI con más información si es necesario)

Generalmente lo hacemos así: el gerente de producto agrega historias con descripciones a la cartera de pedidos del producto. Nuestro scrum master (que también es líder del equipo) revisa esas historias y solicita comentarios adicionales para las historias que no están definidas con suficiente claridad. Durante la semana de planificación, el equipo desglosa cada una de las historias en tareas. Si se generan errores, el líder de nuestro equipo los coloca en el trabajo atrasado, con prioridad asignada también a cada uno de ellos.