La facilitación de la sprint planning marca la diferencia entre un sprint con dirección clara y uno que arranca con dudas. Si eres Scrum Master y buscas que este evento de Scrum sea más productivo, aquí tienes una estructura paso a paso para guiar al equipo, evitar antipatrones y cerrar con compromisos reales basados en valor.

El propósito de la sprint planning es adaptar el producto de cara al siguiente sprint, definiendo incrementos y compromisos a partir del feedback recibido en la review. Vamos a ver cómo facilitarla sin desperdiciar tiempo y manteniendo viva la colaboración.

¿Por qué empezar la sprint planning con un check-in?

Las reuniones rara vez empiezan con todos presentes mentalmente. Llegamos con pendientes, conversaciones recientes y preocupaciones que nos sacan del foco. Por eso, abrir con una actividad de check-in o rompehielo ayuda a traer la atención del equipo al espacio de trabajo [02:14].

La clave está en no abusar. Estas dinámicas son útiles para conocer el estado de ánimo del equipo, no para reemplazar el objetivo del evento.

¿Cuánto debe durar el check-in en una sprint planning? No más de cinco minutos. El propósito del evento no es romper el hielo, sino planificar el sprint, así que úsalo como puerta de entrada y avanza rápido.

¿Cómo se define el objetivo del sprint sin caer en antipatrones?

Después del check-in, el product owner comparte su visión para el siguiente sprint y, en conjunto con todo el equipo Scrum, se acuerda el objetivo del sprint [04:18]. Esto es un acuerdo, no una imposición.

Uno de los antipatrones más comunes ocurre cuando el product owner, por jerarquía o posición, impone el objetivo o las prioridades. Esto choca directamente con el valor del manifiesto ágil: colaboración con el cliente sobre negociación contractual. El equipo Scrum también aporta su visión sobre qué es lo mejor para el sprint.

¿Cómo presenta el product owner el product backlog?

Con el objetivo claro, el product owner presenta el product backlog priorizado por valor, no por orden de llegada [05:42]. Aquí aparece otro antipatrón frecuente: listar el trabajo sin un análisis real de qué genera más valor para el producto.

Buenas prácticas al presentar el backlog:

• Refinar el backlog de forma constante, dejando siempre lo más valioso arriba.
• Presentar las prioridades de mayor a menor valor.
• No abordar el backlog completo si es muy extenso; basta con lo más relevante para ese sprint.

Si el equipo entrega cinco elementos por sprint y el backlog tiene 30, no tiene sentido revisar los 30 en planning.

¿Quiénes definen los compromisos del sprint?

Los developers son quienes deciden qué trabajo van a asumir [07:10]. No es decisión del product owner ni del Scrum Master. Y dentro del equipo de developers, la voz de un senior no debe pesar más que la de los demás. La responsabilidad de la entrega es colectiva.

Los developers colaboran entre ellos y con el product owner para resolver dudas sobre los elementos del backlog. De esa conversación nace el compromiso del sprint.

¿Qué criterio debe pesar al elegir los compromisos del sprint? El valor, no la facilidad de implementación. Comprometerse con lo más fácil en lugar de lo más valioso es un antipatrón clásico que hay que evitar como facilitador.

¿Hay que estimar y refinar dentro de la sprint planning?

Idealmente, no. El refinamiento del backlog y la estimación de elementos deberían suceder en sesiones previas durante el sprint, con el product owner, los developers y, si aplica, algún stakeholder [09:02].

Meter refinamiento y estimación dentro de la planning vuelve el evento tedioso y largo. Solo se justifica cuando una prioridad cambió justo antes del evento y ese ítem no había sido refinado. Es la excepción, no la regla.

¿Cómo se cierra la sprint planning con la conversación de estrategia?

La segunda parte de la planning es táctica. Aquí los developers conversan sobre cómo van a ejecutar el trabajo comprometido. De esta conversación nace el sprint backlog [10:30].

Cuando el equipo tiene clara la forma de trabajar, la planificación está cerrando. Y antes de despedir el evento, dedica un espacio de feedback: ¿qué podemos hacer mejor para que la próxima sprint planning sea más eficiente?

Ese cierre con feedback es una buena práctica que aplica a todos los eventos de Scrum. Cuida siempre el propósito original del evento: si alguien sugiere saltarse el objetivo del sprint o eliminar la estimación, recuerda al equipo por qué la planning existe dentro de los modelos adaptativos de control.

Ahora ve al proyecto del curso, observa cómo el equipo del caso lleva sus sprint planning e identifica qué accionables introducirías como Scrum Master. Cuéntame en los comentarios qué antipatrón has visto con más frecuencia en tus equipos.