¿Cómo mostrar el impacto de la deuda técnica en una simulación de Scrum?

Este es un ejercicio del curso CSD de

La deuda técnica ha de gestionarse

En este post quiero presentar un juego pensado para desarrollar en noventa minutos, en el que los participantes practican cómo incorporar historias técnicas en la planificación de sprint y así reducir la deuda técnica y mantenerla bajo control durante el proyecto.

El objetivo del juego es que el equipo de desarrollo ponga de relieve el valor que aporta resolver deuda para el Propietario del Producto, y balancear historias de usuario y técnicas para maximizar el valor entregado al cliente a largo plazo. Este juego proporciona al equipo el espíritu de colaboración necesario para organizarlo en su propia organización con el Propietario del Producto y mostrar la importancia, para el éxito del proyecto, de la incorporación de historias técnicas que ayuden a disminuir la deuda técnica existente.

La deuda técnica prudente nos hace ser ágiles

Material del juego

El juego incorpora las historias de usuario que tratan funcionalidades para la construcción de una tienda de venta on-line e historias técnicas que implementan técnicas ágiles como integración continua, refactorización y pruebas automatizadas.

Este juego ha sido inspirado en el "The Technical Debt Game de David Croley de Agile Velocity.

He incorporado una serie de variaciones para incorporar elementos para una simulación de Scrum más pedagógica y completa.

Para el juego hacen falta 5 personas, un rol de Propietario del Producto y 4 miembros de equipo. El trainer o facilitador, experto en el juego, hará de Scrum Master. Las tareas del Propietario del Producto serán las rellenar la hoja de registro y de negociar con el equipo la deuda técnica a incluir en el sprint según las siguientes directrices:

• Hacer un sprint de deuda técnica es muy difícil de vender
• Dejar un 10% de puntos de historia para deuda técnica es fácil de vender

Las tareas del equipo serán las de debatir las historias de usuario y deuda técnica a incluir y ejecutar la simulación de cada sprint.

• Para las historias de usuario se basarán en la pila de producto
• Para la deuda técnica aconsejaran y negociaran con el Propietario del Producto
• Para la ejecución cada miembro lanzará un dado una vez por los cinco días de la semana

Paso 0

Dibujar el tablero sobre una hoja de rotafolios:

• Sección A: Pila de Producto
• Sección B: Pila de Producto sólo para deuda técnica que afecta a los sprints
• Sección C: Pila de Sprint
• Sección D: Trabajo en curso
• Sección E: Historias de usuario y deuda técnica finalizada en el sprint
• Sección F: Tarjetas de sprint para leer la correspondiente al finalizar cada sprint

Tablero scrumboard del juego que incorpora la deuda técnica

Paso 1

Hoja de registro marcada con el área cumplimentada en cada paso

Calcular la capacidad del equipo, para ello el Propietario del Producto sumará el impacto de la deuda técnica que afecta a los sprints (sección B). El impacto lo apuntará en la hoja de registro en la fila del impacto y la resta entre la capacidad teórica y el impacto en la capacidad actual para el sprint.

Paso 2

• El equipo decide junto con el Propietario del Producto qué historias de usuario y deuda técnica incluye en el sprint. Se basará en la capacidad actual calculada en el paso 1 y el coste/esfuerzo de cada tarjeta.
• El Propietario del Producto anotará el coste/esfuerzo en la ficha de sprint.
• Las tarjetas elegidas se colocarán en la pila de sprint, en "Pendiente" (Sección C).

Paso 3

• Cada miembro jugará una tirada de dado por cada uno de los cinco días de la semana, una tirada representará los puntos realizados por persona/día.
• Los puntos de dado se aplicarán primero para absorber el total del impacto de la deuda técnica vigente.
• Los puntos de dado restantes se aplicarán restando al coste de las historias de usuario y deuda técnica y se moverán a la columna "En curso" (Sección D). Si el coste queda a 0 se pasarán a la columna "Finalizado" (Sección E).
• El Propietario del Producto anotará el total del equipo en el día correspondiente en la sección de la ejecución del sprint.

Paso 4

Acabado el sprint:

Alumnos en plena ejecución del juego

• Tarjetas que no han pasado a la columna “Finalizado” (Sección E) vuelven a la pila de producto (Sección A) por el total de su coste.
• El Propietario del Producto cumplimentará la zona de resultado de sprint:
• Impacto de la deuda técnica: copiará el impacto del cálculo de la capacidad
• El total de la historias y deuda realizados
• La suma de los tres

Paso 5

Tablero scrumboard del juego en curso

• El Propietario del Producto completará el gráfico del sprint utilizando un color diferente para dibujar la evolución de cada uno de los siguientes valores:
• La capacidad actual
• Total realizado sprint
• Total historias
• Total deuda
• Si se acaba de finalizar el segundo sprint, coger 2 tarjetas de deuda técnica y ponerlas en la zona de la pila de producto que afecta al sprint (Sección B), si es el tercer sprint mover la última.
• Coger una tarjeta de sprint (Sección F) y si tiene impacto se incorpora como deuda técnica vigente (Sección B).
• Reiterar y seguir por el paso 1 hasta que se hayan completado los 5 sprints.

Debate final

Con el gráfico delante el equipo sacará conclusiones sobre cómo ha gestionado la deuda técnica y que mejoraría para la próxima partida.

Hoja de registro con los diferentes gráficos de evolución

Observando la hoja de registro de un juego real podemos ver las diferentes evoluciones del juego:

• Rojo: La velocidad neta del equipo es bastante continuada
• Azul: Los puntos de historia de las historias de usuario crece a medida que se resuelve deuda técnica
• Verde: La deuda técnica bien gestionada decrece a lo largo de los sprints, podemos observar que a medida que bajan los puntos de historia de la deuda técnica se incrementa la de las historias de usuario
• Negro: A medida que se resuelve la deuda técnica el impacto de la misma disminuye

Descargas / Downloads

Las tarjetas con las historias de usuario para el final de cada sprint.

Las tarjetas de deuda técnica.

Las tarjetas de sprint.

La hoja de registro con el resumen de las iteraciones.

---

Primera iteración del juego

A principios de 2015 impulsado por mi compañero Miguel para crear un curso que tratara la deuda técnica, y habiendo visto el artículo de David Croley, me animé a crear la primera versión del juego. Mis compañeros de entonces me apoyaron en las primeras partidas y me dieron su feedback.

Experimentaron como equilibrar la deuda técnica con las historias de usuario, y cómo resolverla les permitía aumentar la velocidad, y como si no lo hacían acababan ahogados por la misma. Recuerdo que comentario que experimentaron lo que todos los equipos de Scrum; los equipos noveles son optimistas y tienen la tendencia a meter mas en los sprints de lo que pueden afrontar.

Gracias chicos por jugarlo por primera vez y dar feedback, gracias Javier, Roberto y Juan