¿Cómo gestionar un bug que se ha detectado en la fase de pruebas con Scrum?

Miembro del equipo de soporte atendiendo

En caso de detección de un bug dentro del mismo sprint, simplemente se resuelve directamente en el mismo sprint. Con este post quiero tratar el caso de bugs detectados en una fase de pruebas posterior al sprint en donde se escribió el código. En este caso lo que dice Scrum es que el bug simplemente se debe de incorporar en la pila de producto para que se resuelva en un sprint futuro. Estuve de co-trainer en un curso con Mike Beedle y en él tratamos su visión de cómo tratar los bugs.

En mis cursos cuando hablo de Scrum y Kanban suelo explicar que Scrum está concebido para el desarrollo productos, y Kanban es una buena herramienta para la fase de mantenimiento y soporte posterior.

La situación ideal es cuando el propio equipo que desarrolló el producto es el que hace el mantenimiento y el que resuelve las incidencias, de esta forma nos beneficiamos de la naturaleza humana y la propiedad colectiva, del orgullo que siente el equipo constructor como "padre" del producto. Si el equipo de mantenimiento es otro, lo que puede ocurrir, y no de forma infrecuente, es que arreglen un bug y generen tres más, y, a la vez, el equipo original deje de sentirse propietario porque otros han modificado el código.

Lo primero que hay que hacer cuando entra un bug es identificar su criticidad, si es un bug no crítico sencillamente hay que recoger información y añadirlo a pila de producto. En caso de bug crítico hay que tomar medidas dentro del sprint actual, desde hacer un intercambio en la pila de producto de una historia de usuario de tamaño semejante por el bug, hasta interrumpir o incluso cancelar el sprint. Bugs críticos se han resolver con urgencia y para ello la mejor receta es aplicar el sentido común. Imaginemos que la base de datos de producción se está corrompiendo, ese es un caso realmente crítico que no puede esperar al sprint siguiente y en el que deberíamos de dejar de hacer lo que estemos haciendo, resolver el problema con los medios necesarios y una vez resuelto regularizar la situación con respecto a Scrum.

Carril bugs sprint anterior - un bug que tiene un bug :-P

Uno de los equipos que acompaño ha incluido un carril para bugs, tienen reservado el 10% de su tiempo para la resolución de bugs y admiten bugs mientras no superen este 10%. Cuando superan el 10% difieren los bugs menos críticos al sprint siguiente, y cuando no llegan al 10% lo que hacen a final de sprint son tareas de refactorización, tareas de mantenimiento como actualización de versiones de ecplise u otros, documentan cosas que tienen pendientes... Abajo podemos ver su tablero a final de sprint, podemos ver los bugs en forma de post-its pequeños.

Tablero scrumboard con un carril para bugs