La lista de verificación de Sprint Planning

Antes del Sprint Planning: lista de verificación de preparación

La mayoría de los fracasos del Sprint Planning comienzan días antes de la reunión.

Preparación del backlog

• El Product Backlog está ordenado con los elementos de mayor prioridad en la parte superior.
• Las historias equivalentes a 1,5× la capacidad del sprint tienen criterios de aceptación aceptados.
• Todas las historias candidatas tienen estimaciones de story points de una sesión reciente de planning poker.
• Ninguna historia candidata tiene una dependencia sin resolver que le impediría comenzar el día uno.
• El Product Owner ha revisado y aprobado las historias principales en el último sprint.

Capacidad del equipo

• La disponibilidad de cada miembro del equipo para el sprint está confirmada.
• La capacidad del sprint ha sido calculada: días disponibles × factor de enfoque.
• Se ha reservado un búfer de capacidad (planifica para el 70–80% del máximo teórico).

Preparación del Sprint Goal

• El Product Owner tiene un borrador del Sprint Goal listo para proponer.
• El Scrum Master ha revisado las historias propuestas y confirmado que apoyan el objetivo.
• Las historias del sprint anterior no completadas han sido evaluadas.

Durante el Sprint Planning: lista de verificación de reunión

El Sprint Planning tiene un timebox recomendado de hasta 8 horas para un sprint de 4 semanas.

Acuerdo del Sprint Goal

• El Product Owner propone el Sprint Goal con contexto: por qué ahora, qué valor entrega.
• El equipo hace preguntas de aclaración y negocia el alcance si es necesario.
• El Sprint Goal se escribe y se acuerda por todo el equipo antes de comenzar la selección.

Selección de elementos del backlog

• El equipo selecciona historias del backlog que apoyan el Sprint Goal.
• Las historias seleccionadas se verifican contra la capacidad del sprint.
• El Product Owner confirma que las historias seleccionadas representan suficiente valor.

Estimación (si es necesario)

• Las historias no estimadas o con alcance significativamente cambiado se estiman usando planning poker.
• Los votos se revelan simultáneamente. Los valores atípicos explican su razonamiento antes de votar de nuevo.
• Las historias que no pueden llegar a consenso en 2–3 rondas se aplazan para refinement.

Desglose de tareas

• El equipo identifica tareas específicas para los primeros 2–3 días del sprint.
• Las dependencias entre tareas se marcan y se acuerdan las asignaciones iniciales.
• Los posibles bloqueadores o riesgos se identifican y se asignan responsables.

Después del Sprint Planning: lista de verificación de cierre

El cierre de la reunión toma 5–10 minutos pero produce artefactos críticos.

• El Sprint Goal está registrado en la herramienta de seguimiento y visible para todos.
• Todas las historias seleccionadas se mueven al sprint en la herramienta.
• Los valores de story points están confirmados para todos los elementos.
• Las fechas de inicio, fin y de revisión/retrospectiva están confirmadas.
• Los elementos discutidos pero no seleccionados regresan al backlog.
• Los puntos de acción se registran con responsables.
• El Sprint Goal se comparte con los stakeholders antes de que comience el sprint.

Recursos relacionados de planning póker

• ¿Qué es Sprint Planning en Scrum?
• Cómo llevar a cabo una reunión Scrum de Sprint Planning
• Planificación Scrum
• header.nav.planningPoker