Con esta solución mantendremos las tareas ya programadas en la planificación del sprint. Al tener sprints de 1 o 2 semanas de duración podremos incluir la tarea no planificada como prioritaria en la lista de cosas a hacer en el siguiente sprint. Si el sprint tiene 1 semana de duración tardaremos una media aproximada 3 días laborales en comenzar a acometer la tarea urgente.

Esto funcionaría en un mundo ideal pero no todas las tareas pueden esperar varios días para ser solucionadas. El servicio entero podría depender de ella.

Si sabemos que con frecuencia nos llegarán tareas inesperadas que debemos resolver con mucha rapidez podemos bajar el factor de dedicación durante el sprint para dar ‘hueco’ a la resolución de estos problemas.

Sabiendo que en cada sprint el equipo tiene capacidad para resolver 10 puntos de historias programadas podríamos comprometernos a entregar solo 7 para que el equipo tenga tiempo de resolver las incidencias urgentes. De este modo no fallaremos un sprint tras otro en entregar lo prometido.

En mi opinión esta solución puede ser útil en ciertos proyectos pero puede crear otro problema. Me explico: Habitualmente el factor de dedicación es del 75%, si lo bajamos para poder dedicar un 30% del tiempo del equipo a las tareas urgentes deberíamos aplicar un factor de dedicación del 40-50%. Sobre este 40% aplicamos SCRUM pero ¿cómo se está gestionando el resto del tiempo del equipo? ¿qué sabemos sobre esa pila de tareas que estamos resolviendo sprint tras sprint?

Esta solución consiste en tener un equipo SCRUM para las tareas identificadas y planeadas y un equipo Kanban para las incidencias de resolución urgente. Con Kanban podemos añadir las nuevas tareas a la columna TO-DO a medida que van llegando y así seguiremos su evolución hasta que llegan a DONE. Con esto el equipo será aún más ágil disminuyendo el overhead de reuniones y planificaciones que tiene SCRUM.

Aún sigue existiendo un problema con las tareas no planeadas y es que son eso, no planeadas. En ocasiones el equipo Kanban que da soporte podría estar sobredimensionado para las pocas incidencias ocurridas en ese momento pero una semana más tarde el número de incidencias y su importancia podría ser tan alta que toda ayuda es poca.

Para minimizar estos riesgos podemos apoyarnos en las soluciones anteriores: Un sprint corto para que el equipo SCRUM de desarrollo planifique sus tareas para la próxima iteración y usar también un factor de dedicación un poco más bajo para que el equipo tener un hueco en su planificación para echar una mano si fuese necesario. Del mismo modo, el equipo de soporte puede colaborar con las tareas planificadas para el sprint actual cuando su columna TO-DO se está quedando vacía. Para aprovechar esto al máximo sería bueno que los miembros de cada equipo se intercambiasen de vez en cuando para que todo el mundo conozca todos los aspectos del trabajo.