Publicaciones

Cómo dirigir reuniones de Sprint Planning que realmente funcionen

El Sprint Planning es la ceremonia de Scrum que da inicio a cada sprint. El equipo decide qué construir, por qué es importante y, a grandes rasgos, cómo lo van a lograr. Cuando funciona bien, todos salen alineados. Cuando no, obtienes dos horas de confusión seguidas de dos semanas de caos. La mayoría de los equipos realizan Sprint Planning (aproximadamente el 86% según la Scrum Alliance), pero muchos lo tratan como una sesión de lectura del backlog en lugar de una verdadera conversación de planificación. Aquí te mostramos cómo hacerlo bien.

Qué produce realmente el Sprint Planning

El resultado del Sprint Planning es el Sprint Backlog, que tiene tres partes:

• Un Sprint Goal, que es una declaración breve sobre por qué este sprint es importante
• Los elementos del backlog seleccionados que el equipo se compromete a completar
• Un plan de entrega sobre cómo el equipo pretende convertir esos elementos en un incremento funcional

El Sprint Goal es la pieza que la mayoría de los equipos omiten, y es la más importante. Sin él, el sprint se convierte en una colección de tareas inconexas sin una dirección coherente.

Quién debe estar en la reunión

Todo el Scrum Team asiste:

Rol	Qué hacen en el Sprint Planning
Product Owner	Presenta los elementos priorizados del backlog, propone el Sprint Goal, negocia el alcance
Scrum Master	Facilita la reunión, controla el timebox, elimina impedimentos
Desarrolladores	Seleccionan el trabajo al que pueden comprometerse, planifican la implementación, descomponen historias en tareas

Se puede invitar a expertos en la materia o stakeholders cuando se necesita su aporte, pero son invitados, no tomadores de decisiones. Un anti-patrón común: enviar solo a uno o dos miembros del equipo para "representar" a los desarrolladores. Si las personas que hacen el trabajo no participan en la conversación de planificación, los compromisos que se les asignan rara vez se cumplen.

La estructura de la reunión

La reunión tiene un flujo natural desde la definición de objetivos hasta la planificación a nivel de tareas.

1. Definir el Sprint Goal

   El Product Owner propone por qué este sprint es importante y qué valor debe entregar. El equipo trabaja en conjunto para convertirlo en un Sprint Goal claro. Si necesitas un punto de partida, prueba un generador de sprint goals. Comienza aquí, no con el backlog. El objetivo le da dirección a todo lo demás.

2. Revisar la capacidad

   Antes de seleccionar cualquier trabajo, verifica la disponibilidad real. ¿Quién está de vacaciones? ¿Quién está de guardia? Un enfoque confiable: promedia la velocidad de tus últimos tres sprints con una calculadora de velocidad de sprint y luego ajusta según los cambios de capacidad conocidos.

3. Seleccionar elementos del backlog

   El Product Owner presenta los elementos de mayor prioridad (que ya deberían estar refinados y estimados). Los desarrolladores seleccionan aquello que tienen confianza de poder completar, dada su capacidad y la Definition of Done. Esto es una negociación, no una asignación de arriba hacia abajo.

4. Descomponer en tareas

   Para cada elemento seleccionado, los desarrolladores dividen el trabajo en tareas más pequeñas, idealmente completables en un día o menos. Aquí es donde la complejidad oculta y las dependencias salen a la luz antes de convertirse en sorpresas a mitad del sprint.

5. Confirmar el Sprint Backlog

   El equipo revisa el panorama completo: Sprint Goal, elementos seleccionados, plan de entrega. Todos deberían salir de la reunión siendo capaces de explicar de qué trata el sprint y en qué van a trabajar primero.

Cuánto tiempo debería tomar

La Guía de Scrum establece máximos, no objetivos:

Duración del sprint	Tiempo máximo de planificación
1 semana	2 horas
2 semanas	4 horas
3 semanas	6 horas
4 semanas	8 horas

En la práctica, la mayoría de los equipos con sprints de 2 semanas terminan la planificación en 60-90 minutos cuando el backlog ha sido bien refinado previamente. Si constantemente alcanzas el timebox completo, es un problema de refinamiento, no de planificación.

Dónde encaja la estimación

Aquí es donde muchos equipos se equivocan. La estimación debería ocurrir antes del Sprint Planning, durante el refinamiento del backlog, no al inicio de la reunión. Mike Cohn, quien creó Planning Poker, identifica dos buenos momentos para estimar:

1. Después de talleres de escritura de historias, cuando un lote de 20-50 elementos nuevos necesita dimensionamiento
2. Durante sesiones regulares de refinamiento, a medida que los elementos se clarifican a lo largo del sprint

Y un mal momento: al inicio del Sprint Planning. Para entonces es demasiado tarde para que el Product Owner ajuste las prioridades basándose en las nuevas estimaciones, y los desarrolladores que están cambiando mentalmente al modo de ejecución tienen dificultades con el dimensionamiento relativo de alto nivel. Cuando la parte superior del backlog llega al Sprint Planning ya estimada, la reunión se convierte en un ejercicio de selección ("¿cuánto de este trabajo estimado cabe en nuestra capacidad?") en lugar de un debate de estimación. Esa es la diferencia entre una sesión de 90 minutos y una de 3 horas. Si tu equipo usa Planning Poker para estimar, realiza esas sesiones durante el refinamiento. Herramientas como Kollabe soportan estimación asíncrona para que los equipos puedan estimar en su propio tiempo sin bloquear a todo el grupo.

Errores que descarrilan el Sprint Planning

Mala preparación del backlog. Llegar a la planificación con historias vagas y sin refinar es la causa número uno de reuniones largas y frustrantes. Si los criterios de aceptación no están claros antes de la reunión, no se van a aclarar durante ella. Sin Sprint Goal. Sin un objetivo, no hay forma de tomar decisiones de compromiso cuando el alcance se ajusta. Terminas con una lista desconectada de tareas en lugar de un sprint coherente. Sobrecomprometerse. Si regularmente mueves entre el 30-40% del trabajo no terminado al siguiente sprint, estás asumiendo más de lo que el equipo puede entregar. La mayoría de los equipos pierden entre el 15-25% de su sprint en trabajo no planificado, reuniones y overhead. Inclúyelo en el cálculo. Omitir el "cómo". Seleccionar historias sin discutir la implementación significa que las sorpresas aparecen a mitad del sprint. Incluso cinco minutos dedicados al enfoque previenen la mayoría de estas situaciones. Tratarlo como una reunión de estado. El Sprint Planning mira hacia adelante. Si estás dedicando tiempo a actualizaciones sobre lo que sucedió en el sprint anterior, eso pertenece a la revisión del sprint o la retrospectiva.

Cómo mejorar el Sprint Planning con el tiempo

Si mejoras una sola cosa, que sea el refinamiento del backlog. La Guía de Scrum recomienda dedicar entre el 5-10% del total de horas del sprint al refinamiento. Cuando las historias llegan a la planificación con criterios de aceptación claros, dependencias conocidas y estimaciones existentes, la reunión prácticamente se conduce sola. Además de eso:

• Comparte los elementos candidatos 1-2 días antes para que los desarrolladores puedan pensar en los enfoques con anticipación
• Comienza con el Sprint Goal, no con el backlog. Proporciona foco y facilita las decisiones de alcance
• Deja que los desarrolladores sean dueños del "cómo". El Product Owner negocia qué se construye, los desarrolladores deciden cómo
• Reserva capacidad para deuda técnica. Los equipos experimentados asignan hasta un 20% de su sprint para bugs y refactorización
• Incorpora los elementos de acción de la retrospectiva. Si el equipo acordó cambiar algo en el sprint pasado, debería aparecer en el plan de este sprint

Sprint Planning en el panorama general

El Sprint Planning es una ceremonia dentro de un ciclo, y funciona mejor cuando las demás también cumplen su papel. Las retrospectivas revelan mejoras de proceso que alimentan el plan del siguiente sprint. Las revisiones del sprint muestran feedback de los stakeholders que moldea las prioridades. Los daily standups adaptan el plan a medida que las cosas cambian. Y el refinamiento del backlog prepara la materia prima que hace eficiente el Sprint Planning. Cuando el resto del ciclo está saludable, el Sprint Planning se convierte en la reunión más corta, no la más larga.