Plantilla de agenda de sprint planning para equipos de ingeniería
Por qué los sprints se sobrecargan
El sprint planning tiene un fallo estructural que las plantillas no previenen: los equipos seleccionan el backlog del sprint antes de que nadie revise la capacidad. El resultado es un sprint que parecía alcanzable en la pizarra y se derrumba el miércoles cuando dos ingenieros están fuera la mitad de la semana, un ticket triplica su alcance y tres elementos tenían dependencias no declaradas de un servicio que el equipo de plataforma está reescribiendo.
La solución es sencilla y casi nunca se aplica: comprometerse con la capacidad antes de comprometerse con el trabajo. La plantilla de abajo abre con una revisión de capacidad exactamente por eso.
La agenda (copia y pega esto)
Duración: 2 horas para un sprint de 2 semanas; 1 hora para un sprint de 1 semana Formato: Facilitado, con el backlog visible para todo el equipo
Sección 1 — Objetivo del sprint (10 min)
- Una frase: ¿cómo se ve un sprint exitoso desde fuera?
- El objetivo debe ser lo suficientemente específico para que cualquier miembro del equipo pueda evaluar al final del sprint si se alcanzó
- Rechaza objetivos que sean simplemente una lista de tickets ("terminar el refactor de auth y la página de facturación"); eso es un backlog, no un objetivo
Sección 2 — Revisión de capacidad (15 min)
- Lista a cada miembro del equipo por nombre
- Por cada uno: PTO planificado, rotación de guardia, reuniones recurrentes, compromisos externos conocidos
- Expresa la capacidad en story points disponibles o días, no en número de personas
- Este número es el techo; no selecciones más trabajo del que soporta
Sección 3 — Selección del backlog (45 min)
- Revisa los elementos de mayor prioridad del backlog refinado
- Por cada candidato: ¿tiene el equipo lo suficiente para empezarlo, o hay preguntas abiertas que necesitan respuesta antes de que empiece el sprint? Las preguntas abiertas pertenecen a la cola de refinamiento, no al sprint
- Deja de seleccionar al llegar al 80 % de la capacidad; el 20 % restante absorbe el spillover y el trabajo no planificado
Sección 4 — Criterios de aceptación (20 min)
- Por cada elemento seleccionado: declara el criterio que lo hace «listo»
- Si el equipo no puede enunciar un criterio en 60 segundos, el ticket no está lo suficientemente refinado; devuélvelo al backlog
- Escríbelo en el ticket ahora, en la sala; no confíes en "lo añadimos después"
Sección 5 — Riesgos y dependencias (15 min)
- ¿Qué podría bloquear la entrega del objetivo del sprint fuera del control del equipo?
- Nombra al dueño de la dependencia; sácalo ahora mientras hay tiempo para resolverlo antes de la mitad del sprint
- Las dependencias sin resolver quedan asignadas a un responsable del equipo que las seguirá
Cierre (15 min)
- Confirma que el objetivo del sprint sigue siendo válido dado el trabajo seleccionado
- Asigna al encargado del resumen del sprint, o confirma la configuración del informe automatizado
- Confirma la próxima fecha de planning
Lo que la mayoría de las plantillas de sprint planning no cubren
Las plantillas de sprint planning más populares se centran en el grooming del backlog y en la definición de «hecho». Ambas son importantes. Ninguna aborda el error de planificación que produce más fallos de sprint: seleccionar trabajo sin revisar la disponibilidad.
Un equipo de cinco ingenieros a plena capacidad tiene aproximadamente 200 story points disponibles por sprint de 2 semanas. Un equipo de cinco con dos ingenieros de vacaciones, uno en guardia y uno en un offsite de tres días tiene quizás 110. Si seleccionas 180 puntos en ese segundo sprint, ya has fallado. La selección es donde ocurre el sobrecompromiso, y la capacidad debe precederla.
La segunda brecha son los criterios de aceptación. Los equipos avanzan rápido en el planning con la intención de escribirlos después. Después no sucede con el mismo nivel de especificidad. La persona que habría escrito un criterio preciso en la sala escribe algo más vago de memoria al día siguiente, o directamente no lo escribe. Los desacuerdos a mitad del sprint sobre qué significa «hecho» son casi siempre rastreables hasta criterios de aceptación omitidos en el planning.
El coste acumulado de estas brechas —sprints sobrecargados, descubrimientos a mitad del sprint, definiciones que se vuelven a debatir— se ve claramente cuando lo sumas: El impuesto de las reuniones.
Por qué las notas de sprint planning son más difíciles de lo que parecen
El sprint planning genera más información que casi cualquier otra reunión recurrente: el objetivo del sprint, los números de capacidad, la justificación de selección elemento por elemento, los criterios de aceptación por ticket, los dueños de dependencias, los riesgos. Escribir un resumen útil requiere capturar todo eso en una forma que sea útil tres días después cuando alguien pregunta "¿por qué recortamos ese elemento?".
Pavleur genera el informe de sprint planning automáticamente al final de la llamada. Captura el objetivo del sprint, el backlog seleccionado con justificación, los criterios de aceptación tal como se enunciaron en la reunión y los dueños de dependencias tal como se nombraron. Si alguien compartió pantalla con el backlog o la hoja de cálculo de capacidad, ese visual aparece en el informe junto a la discusión: contexto que herramientas solo de audio como Otter o Fireflies perderían por completo. Quien se incorporó tarde o necesita consultar una decisión a mitad del sprint tiene el registro completo. Para una comparación de cómo esto difiere de las herramientas solo de audio: Pavleur frente a alternativas.
Gestionar el cambio de plan a mitad del sprint
El plan del sprint es un compromiso, no un contrato. Cuando algo a mitad del sprint invalida genuinamente el plan —un incidente en producción, una dependencia crítica que bloquea tres tickets, un cambio de prioridades desde dirección— la respuesta correcta es una reunión rápida de re-planificación, no una reducción silenciosa del alcance. La reunión de re-planificación lleva 20 minutos y produce un objetivo de sprint actualizado que refleja la realidad. La alternativa es un sprint que falla en el papel pero se ajustó informalmente de maneras que nadie anotó, lo que dificulta la retrospectiva y hace que los números de velocidad no signifiquen nada.
Construye el hábito de la re-planificación explícita. Usa la misma estructura: capacidad actualizada, selección revisada, objetivo reformulado. Lleva mucho menos tiempo que la confusión que previene.