¿Cómo lidiar con tareas recurrentes en un sprint?

Un tema común en los métodos ágiles es la comunicación, la visibilidad y la transparencia en el trabajo que se está realizando y cuál es el estado de ese trabajo, asegurando que las partes interesadas adecuadas tengan acceso a esta información.

Sin conocer todos los detalles sobre este trabajo, parece que Product Backlog no es el lugar adecuado para estos. La Guía Scrum define Product Backlog como "una lista ordenada de todo lo que se sabe que se necesita en el producto". A menos que este trabajo represente algo que el producto necesita, simplemente me aseguraría de que el trabajo se coloque en el Sprint Backlog durante la Planificación del Sprint. Esto puede ayudar al equipo a asegurarse de que lo tengan en cuenta al elaborar el objetivo del Sprint y seleccionar los elementos de la cartera de pedidos del producto para el Sprint. Pondría cada tarea como un elemento separado en el Sprint Backlog e incluso las estimaría como lo haría con otro trabajo para poder mostrar el impacto de este trabajo necesario en la capacidad de entregar otro trabajo para el producto.

Sin embargo, a largo plazo, parece que el trabajo regular que involucra el 40% de la capacidad es algo que debe abordarse. Me preguntaría si un equipo de desarrollo representa a las personas que deberían hacer este trabajo. Alternativamente, me gustaría saber si hay formas de automatizar el proceso hasta cierto punto para que la carga pueda reducirse, especialmente si es un proceso continuo.

¿Cómo lidiar con tareas recurrentes en un sprint?

Realmente depende de qué tipo de trabajo se realiza en esas tareas recurrentes.

Si el trabajo se trata de corregir errores para la aplicación, agregar nuevas funciones, cualquier tipo de mejora del producto o trabajo que cree un incremento del producto y pueda ser un objetivo para los sprints, entonces pertenece a su sprint y a su backlog y usted lo maneja. como cualquier otra historia.

Si el trabajo toca más del lado de la asistencia al usuario (comprobación manual de datos, verificación de información diversa para responder a las preguntas de los usuarios, ofrecer asistencia por teléfono/chat/correo electrónico, etc.), entonces probablemente sea mejor sacar este trabajo de sus sprints y de tu cartera de pedidos. He trabajado con equipos que funcionaban en entornos similares y encontraron una solución simple y efectiva:

• sacaron a una persona del sprint y la pusieron a trabajar en "operaciones";
• se creó un tablero Kanban y un backlog separados para esta actividad;
• para mantenerlo justo para todos, fue un desarrollador diferente en cada sprint, por rotación;
• este desarrollador no participaría en el desarrollo del trabajo en el sprint, pero podría asistir a la planificación del sprint, las reuniones diarias y las retrospectivas, para mantenerse al tanto de lo que sucedía en el sprint mientras manejaba las "operaciones";
• cualquier trabajo que hicieran mientras estaban fuera del sprint se registraba en el tablero Kanban. Si era estrictamente soporte, permanecía en el tablero de Kanban y en el backlog de Kanban. Si resultaba ser algo que mejoraba el producto, crearían elementos de backlog en el backlog de Scrum y dejarían que los demás se encargaran de ello (es decir, si era soporte, ellos se ocupaban del trabajo. Si era desarrollo de productos, arrojaban el trabajo sobre la mesa). cerca al equipo Scrum que lo manejó como cualquier otro elemento en su tubería).

Este enfoque mantuvo las cosas en movimiento en ambas canalizaciones (soporte y desarrollo) y protegió al equipo de Scrum del trabajo que tenía poco que ver con las mejoras del producto. La persona que brindaba apoyo a veces no se utilizaba por completo, pero ese no era el punto .

Finalmente, si el trabajo repetitivo se puede automatizar, hágalo y haga que una máquina haga el trabajo.