Trabajo planificado y no planificado en Scrum

La mayoría de los equipos que empiezan a trabajar con Scrum entienden su Backlog y los llamados "trabajos planificados". Son los trabajos que todos han recopilado juntos y que comprenden completamente. Y luego está todo lo demás... Estas son las cosas a las que los nuevos equipos Scrum deben prestar atención en su primer Sprint. Todas las cosas que realizan independientemente del trabajo planificado para ese Sprint se listan con las horas necesarias en la columna de "trabajo no planificado".

Después del primer Sprint, los equipos frecuentemente se sorprenden de cuánto se acumula. La mayoría son diversas tareas que se han estado realizando todos los días o cada semana desde hace mucho tiempo. A menudo las llamamos tareas de "Business-as-Usual" (BAU), aunque en otras empresas pueden tener otros nombres. Luego están las reuniones ad-hoc y otras cosas que hacemos sin pensarlo mucho. Pueden ser tareas BAU o simplemente interrupciones.

Además están las emergencias que deben atenderse inmediatamente. A menudo esto se categoriza como "soporte", aunque podría tener cualquier otro nombre.

Algunas de estas cosas ya las conocemos durante el Sprint Planning. Entonces se añaden al Sprint Backlog como parte de los compromisos. Si aparecen repetidamente, quizás deberías pensar en crear una columna propia para ellas y reservar cierta capacidad para estas cosas.

¿Qué hacer con el trabajo no planificado en Scrum?

Programa una reunión para examinar más de cerca las tareas recurrentes y descubrir cómo mejorar el trabajo con ellas. El objetivo es automatizarlas o al menos reducirlas lo más posible.

Los elementos que no se pueden considerar en el Sprint Planning son aquellos que surgen durante el Sprint y no se pueden prever. Los llamamos "no planificados". Cada equipo tiene algo de este trabajo no planificado y debe descubrir cómo manejarlo. Aquí también deberías reflexionar regularmente sobre qué puedes hacer para reducir este trabajo no planificado tanto como sea posible. Cuanto más trabajo no planificado tenga un equipo, menos trabajo adicional podrá asumir. Idealmente, la mayor parte del trabajo de un equipo Scrum debería ser trabajo planificado. Cada equipo debe evaluar sus capacidades y descubrir cómo trabajar mejor con ellas.

Estos son algunos de los métodos que ya he visto en equipos:

Límites y reglas

Todo trabajo no planificado se anota en el tablero y se prioriza. Sin embargo, la columna de Work-in-Progress tiene un límite de cuántos trabajos pueden abordarse simultáneamente, por ejemplo dos. Así que solo se puede trabajar en dos cosas diferentes al mismo tiempo. El resto del equipo puede concentrarse en los trabajos planificados para el Sprint. También se pueden establecer reglas sobre qué elementos no planificados pueden escribirse en el tablero y cuándo, etc.

Una persona por día/semana/Sprint

También se puede crear un plan que establezca quién está asignado para trabajar en cosas no planificadas. Así el resto del equipo también puede concentrarse en los trabajos planificados. Si esa persona no entiende algo o tiene un problema, puede pedir ayuda a los otros miembros del equipo. Esto puede rotarse diariamente, semanalmente o en cada Sprint.

Una ventana de tiempo específica

También se puede establecer una ventana de tiempo para el trabajo no planificado. Esto puede ser, por ejemplo, entre las 09:00 y las 11:00 horas; el resto del día laboral está reservado para los elementos del Sprint.

Días fijos

También se pueden programar ciertos días de la semana para trabajar en cosas no planificadas, por ejemplo, martes y jueves. Todos los demás días laborables son solo para trabajos planificados.

Los equipos Scrum pueden turnarse

Si varios equipos Scrum trabajan en el mismo Backlog, los equipos pueden turnarse para trabajar en cosas no planificadas. El equipo A trabaja en este Sprint solo en elementos no planificados y el equipo B trabaja en los elementos del Backlog.

Seguramente has notado que en todos los ejemplos se les da a los equipos un período de tiempo concreto para trabajar en los elementos del Backlog. No hay un patrón fijo para esto y seguramente hay más posibilidades que las mencionadas anteriormente. Si tú también tienes este problema, simplemente prueba algunas de estas sugerencias y descubre qué funciona mejor para ti.

Este texto proviene del blog de Growing Agile y fue puesto a nuestra disposición.