8. Ejecución del Sprint

Una vez que la planificación del sprint ha terminado, comienza la ejecución del sprint. Este es el período, generalmente de 1 a 4 semanas, en el que el Equipo de Desarrollo trabaja para construir el incremento de producto. Durante este tiempo, el equipo es autoorganizado y se enfoca en cumplir el Objetivo del Sprint.

8.1. Seguimiento del progreso (tablero Kanban / burndown chart)

La transparencia es clave en Scrum. Para que todos (el equipo, el Product Owner, los stakeholders) puedan ver el progreso del trabajo, se utilizan herramientas visuales.

Tablero Kanban

El tablero Kanban es la herramienta más común. Es un tablero (físico o digital) con columnas que representan los estados del flujo de trabajo. Como mínimo, un tablero suele tener tres columnas:

  • To Do (Por Hacer): Contiene todas las tareas del Sprint Backlog que aún no se han iniciado.
  • In Progress (En Progreso): Contiene las tareas en las que el equipo está trabajando activamente.
  • Done (Hecho): Contiene las tareas que se han completado, cumpliendo con la Definición de "Hecho".

El equipo mueve las tarjetas (que representan las tareas o historias) de una columna a otra a medida que avanzan. Esto proporciona una visión clara y en tiempo real de qué se está haciendo, quién lo está haciendo y dónde pueden existir cuellos de botella.

Burndown Chart

El gráfico de burndown es otra herramienta útil. Muestra la cantidad de trabajo restante en el sprint a lo largo del tiempo. El eje vertical representa el esfuerzo (generalmente en story points o en horas de tareas) y el eje horizontal representa los días del sprint.

Una línea ideal muestra cómo debería "quemarse" (reducirse) el trabajo si todo fuera perfecto. La línea real muestra el progreso real del equipo. Al comparar ambas líneas, el equipo puede ver si va por buen camino para completar todo el trabajo comprometido o si necesita tomar medidas para volver a encarrilarse.

8.2. Daily Scrum: propósito, duración y formato

La Daily Scrum (o reunión diaria) es una reunión corta, de no más de 15 minutos, que se celebra todos los días a la misma hora y en el mismo lugar. Su propósito no es un reporte de estado para un gerente, sino una oportunidad para que el Equipo de Desarrollo se sincronice, inspeccione el progreso hacia el Objetivo del Sprint y planifique el trabajo para las próximas 24 horas.

Tradicionalmente, cada miembro del equipo responde a tres preguntas:

  1. ¿Qué hice ayer que ayudó al equipo a alcanzar el Objetivo del Sprint?
  2. ¿Qué haré hoy para ayudar al equipo a alcanzar el Objetivo del Sprint?
  3. ¿Veo algún impedimento que me impida a mí o al equipo alcanzar el Objetivo del Sprint?

Es importante que la Daily Scrum se centre en el objetivo y no se convierta en una sesión de resolución de problemas. Si durante la reunión surgen temas que requieren una discusión más larga, se deben tratar después de la Daily Scrum, solo con las personas necesarias.

8.3. Adaptación ante imprevistos y gestión de bloqueos

Ningún plan sobrevive al contacto con la realidad. Durante el sprint, es normal que surjan imprevistos, problemas técnicos o bloqueos (impedimentos). La clave es cómo el equipo se adapta a ellos.

Un bloqueo o impedimento es cualquier cosa que impide a un miembro del equipo o al equipo en su conjunto progresar. Puede ser un problema técnico, una dependencia de otro equipo, una pregunta sin respuesta para el Product Owner, etc.

La gestión de bloqueos es una responsabilidad crucial del Scrum Master. Cuando un miembro del equipo identifica un bloqueo en la Daily Scrum, el Scrum Master se encarga de:

  • Hacer visible el bloqueo: A menudo se marca la tarea bloqueada en el tablero Kanban con un post-it rojo o una etiqueta.
  • Facilitar la resolución: El Scrum Master no necesariamente resuelve el problema él mismo, sino que se asegura de que la persona o personas adecuadas se pongan a trabajar en ello. Su trabajo es eliminar el obstáculo para que el equipo pueda seguir siendo productivo.
  • Proteger al equipo: El Scrum Master protege al equipo de interrupciones externas y se asegura de que puedan centrarse en el trabajo del sprint.

Si surge un problema que pone en riesgo el Objetivo del Sprint, el equipo debe colaborar con el Product Owner para decidir cómo adaptarse. ¿Se puede simplificar una historia? ¿Se puede sacar una historia del sprint para liberar capacidad? La comunicación abierta y la capacidad de adaptación son fundamentales para el éxito del sprint.