El sprint planning es la reunión que un equipo Scrum celebra al inicio de cada sprint para responder a tres preguntas: qué entregará este sprint (Sprint Goal), qué elementos del backlog entran (Sprint Backlog) y cómo se construirá cada uno (desglose y enfoque). Al terminar la reunión, el equipo arranca con un objetivo de sprint claro y una lista de tareas ejecutable.
La versión de 30 segundos
- Frecuencia: una vez por sprint, fijo el primer día de la iteración;
- Duración: sprint de dos semanas → máximo 2 horas; sprint de una semana → 1 hora;
- Asistentes: todo el equipo Scrum — desarrolladores, Product Owner, Scrum Master;
- Resultado: 1 Sprint Goal + 1 Sprint Backlog (desglosado en tareas ejecutables);
- Prueba de paso: al salir de la reunión, cada miembro puede decir de memoria «esto es lo que construimos este sprint.»
Dónde encaja el sprint planning en el ciclo
Sprint Planning (día 1)
↓
Daily Standup × 9 días
↓
Sprint Review (demo) + Sprint Retrospective
↓
Siguiente Sprint Planning
El planning consume los productos del paso anterior: el Product Backlog y las acciones de mejora de la última retrospectiva. Cómo se relacionan ambas reuniones: ver la guía de sprint retrospective.
La preparación previa (la mitad de la eficacia de la reunión)
| Elemento de preparación |
Responsable |
Estándar |
| Product Backlog ordenado |
Product Owner |
Los primeros candidatos están lo bastante claros — no hace falta explicar el contexto en directo |
| Candidatos refinados |
Product Owner + equipo dev |
1,5–2× la capacidad del top de la lista está desglosado/estimado |
| Capacidad del equipo calculada |
Scrum Master |
Días-hombre efectivos tras vacaciones, reuniones y guardias |
| Acarreo del sprint anterior decidido |
Equipo dev |
Elementos sin terminar: ¿al backlog o a este sprint? — decidido antes de la reunión |
| Definition of Done lista |
Equipo |
Todos coinciden en qué significa «terminado» |
Sin un backlog preparado, el planning se convierte en una reunión de aclaración de requisitos — la causa más común de pasarse de tiempo.
Plantilla de agenda (ejemplo de 2 h para un sprint de dos semanas)
| Hora |
Segmento |
Qué pasa |
| 0:00–0:10 |
Fijar el objetivo |
El PO propone el resultado de negocio buscado; el equipo lo condensa en un Sprint Goal de una frase (p. ej. «los admins pueden exportar informes») |
| 0:10–0:50 |
Elegir elementos |
Recorrer el backlog en orden: ¿entra este? Restar contra la capacidad hasta llenarla |
| 0:50–1:40 |
Desglosar tareas |
Para cada elemento elegido, desglosar tareas de 0,5–1 día y anotar el enfoque técnico; los riesgos técnicos discutidos se zanjan en el momento |
| 1:40–1:55 |
Riesgos y dependencias |
Dependencias externas (APIs de terceros, diseños, otros equipos), guardias, prioridad de bugs conocidos |
| 1:55–2:00 |
Confirmar y comprometerse |
Repetir el Sprint Goal y la lista; todos confirman; nombrar las tareas de arranque del primer día |
Cómo calcular las tres entradas clave
1. Capacidad
Días-hombre efectivos = miembros × días laborables − vacaciones − sobrecoste de reuniones − ajuste de guardias
Ejemplo: equipo de 5, 10 días laborables, 3 días de vacaciones en total, reuniones fijas que cuestan ~2 días-hombre → 45 − 3 − 2 = 40 días-hombre efectivos.
2. Velocidad
Tomar la media o la mediana de los story points terminados en los últimos 3–5 sprints (la mediana resiste mejor los picos). ¿Equipo nuevo sin historial? Estimar desde la capacidad: 1 día-hombre ≈ 1 unidad de trabajo efectivo, y pasar a story points tras dos sprints. Ideas erróneas sobre la velocidad: ver la FAQ.
3. Estimación
- Planning Poker es la herramienta habitual: todos revelan carta a la vez; los elementos con mucha dispersión se discuten y reestiman;
- Regla de granularidad: los elementos de más de 8 puntos se parten antes de entrar al sprint;
- Los puntos estiman esfuerzo relativo, no horas — nunca los uses para evaluar el rendimiento individual.
Errores comunes y correcciones
| Error |
Consecuencia |
Corrección |
| Planificar al 100 % de la capacidad |
Cero margen; un bug sorpresa tumba el sprint |
Planificar al 80 % de la capacidad; dejar sitio para defectos imprevistos y sobrecoste de coordinación |
| El PO solo cuenta los requisitos de palabra en la reunión |
La reunión se convierte en aclaración de requisitos |
Refinar los elementos antes de la reunión; durante, confirmar — no dar clase |
| Elegir elementos sin desglosarlos |
El «cómo» se improvisa a mitad de sprint, cuando ya es tarde |
Desglosar en tareas de 0,5–1 día y repasar el enfoque técnico |
| El objetivo es una lista de elementos, no un resultado de negocio |
El equipo responde por «terminado», no por «útil» |
El Sprint Goal debe ser una frase orientada al negocio |
| Los bugs del sprint anterior nunca priorizados |
El plan del nuevo sprint queda destrozado por defectos sorpresa |
Decidir el destino de los bugs arrastrados en la reunión (ver la sección siguiente) |
¿Dónde van los bugs del sprint?
Una parte del planning que suele saltarse: qué defectos atenderá este sprint y de quién es la mecánica de triage en marcha. Dejarlo explícito en la reunión:
La lista de bugs arrastrados y su destino (arreglar / degradar / cerrar);
El flujo de los bugs nuevos durante el sprint: triage → clasificar (P0 el mismo día, P1 a este sprint, P2 al backlog). Cómo hacerlo: la guía de bug triage;
Una única entrada para los informes de bug: los reportes de testers o usuarios deben traer pasos de reproducción, capturas y errores de Console — no dispersos por los chats de grupo.
El punto 3 es la palanca oculta de la velocidad del sprint: un informe con contexto completo deja al desarrollador arreglando al instante, sin preguntas de ida y vuelta. El enfoque de BugCapturer: cada envío adjunta automáticamente una captura/grabación anotada, la URL, el entorno del navegador y los errores de Console/Network (ver la función de diagnóstico), y los informes se empujan automáticamente a un canal de Slack / Microsoft Teams — en el planning, los defectos se clasifican directamente desde los informes del canal, sin gastar tiempo de reunión en «¿a ver, cuál era exactamente el problema?».
FAQ
P: ¿Qué es una reunión de sprint planning?
R: La reunión de planificación del inicio de cada sprint en Scrum; decide el alcance (qué) y el enfoque (cómo), y produce el Sprint Goal y el Sprint Backlog.
P: ¿Qué es el sprint planning desde la óptica de un business analyst (BA)?
R: El BA se fija en la testabilidad y los criterios de aceptación: los elementos elegidos traen condiciones de aceptación y casos límite claros, y traduce las necesidades de los stakeholders a elementos del backlog.
P: ¿Cuánto debe durar el planning?
R: Regla empírica: máximo 1 hora por semana de sprint — sprint de una semana, 1 hora; de dos semanas, 2. Los excesos suelen indicar un refinamiento insuficiente antes de la reunión.
P: ¿Cómo hace el planning un equipo remoto?
R: Videollamada + tablero compartido (Jira/Linear/Trello) como siempre; durante el desglose, escribir en paralelo en una pizarra colaborativa — aproximadamente el doble de rápido que leer los elementos en serie.
P: A mitad de sprint nos damos cuenta de que el plan era pequeño. ¿Y ahora qué?
R: No metas nada a mitad de sprint. Anótalo y dale prioridad en el próximo planning; lo urgente pasa por el carril de triage P0.