Acerca de esta plantilla
La mayoría de los equipos planifican sus sprints con tickets de Jira y un backlog, y acaban perdiendo de vista cuándo se entrega realmente cada pieza. Una vista Gantt de un único sprint muestra el calendario real: cuándo diseño entrega a desarrollo, cuándo cada historia está en revisión, cuándo QA la recibe, cuándo es la demo. Esta plantilla de 2 semanas se puede clonar para cada sprint o usarse para planificar una release más larga como una cadena de sprints.
Cómo se reparte un sprint de 2 semanas
Arranque del sprint
Reunión de sprint planning: revisión del backlog, estimación de historias, capacidad frente a velocidad, objetivo del sprint. Confirma que todos tienen sus historias asignadas. Termina con un objetivo del sprint de una sola frase que cualquiera del equipo pueda repetir.
- Refinamiento del backlog
- Estimación de puntos de historia
- Comprobación de capacidad frente a velocidad
- Asignación de historias
- Objetivo del sprint
Días 2–4 — Diseño e inicio
Los diseñadores cierran las especificaciones pendientes. Los desarrolladores empiezan primero por las historias más grandes (para adelantar el riesgo en el sprint). Reunión diaria siempre a la misma hora — 15 minutos, tres preguntas por persona.
- Reunión diaria
- El diseñador entrega las especificaciones
- Los desarrolladores empiezan por las historias más grandes
- PR con plantilla y SLA de revisión confirmados
Días 5–8 — Desarrollo
Desarrollo a fondo. Las revisiones de código son continuas (objetivo: el PR abierto menos de 24 horas antes de la primera revisión). Seguimiento a mitad de sprint el día 7 — señala cualquier historia en riesgo de retrasarse.
- Reunión diaria
- Revisiones de código (SLA de 24h)
- Seguimiento a mitad de sprint (día 7)
- Reajuste de historias en riesgo
Días 9–11 — QA y fusión
Las historias se completan y quedan listas para QA. Los arreglos de errores de QA vuelven a los desarrolladores. Al final del día 11, toda historia lista para entregar está fusionada. Lo que no llega se devuelve al backlog.
- Pase de QA sobre las historias completadas
- Ciclo de corrección de errores
- Fusión a main
- Actualización de las notas de versión
Días 12–14 — Demo y retrospectiva
Día 12: despliegue a staging, pruebas de humo. Día 13: demo del sprint para los interesados — cada responsable de historia presenta su trabajo. Día 14: retrospectiva — qué fue bien, qué nos frenó, qué probar en el próximo sprint. Programa el arranque del próximo sprint.
- Despliegue a staging
- Pruebas de humo
- Demo del sprint
- Retrospectiva
- Arranque del próximo sprint
Consejos de equipos con sprints fluidos
- Empieza primero por la historia más grande. Adelanta el riesgo en el sprint, no lo dejes para después.
- Abre cada PR en las 24 horas siguientes a que el trabajo esté listo. Los PR sin abrir son retrasos silenciosos.
- Haz el seguimiento a mitad de sprint el día 7. Las historias en riesgo el día 7 aún se pueden salvar; el día 12 ya no.
- Termina cada retrospectiva con un cambio concreto para el próximo sprint. Las listas de 15 ideas no producen ningún cambio.
- Haz la demo aunque la mitad de las historias no haya llegado. Mostrar el trabajo parcial genera presión para entregar.
Preguntas frecuentes
¿Es útil el Gantt para sprints ágiles?
Sí — para la vista de un único sprint, hace visibles la secuencia de historias y las entregas de un modo que un tablero Kanban no consigue.
¿Debería hacer esto en cada sprint?
Un Gantt de un único sprint es más útil en los primeros 3–5 sprints de un equipo nuevo, o en cualquier sprint con dependencias entre equipos.
¿Puedo encadenar varios sprints en un plan de release?
Sí. Abre esta plantilla y añade 2–3 bloques más de 2 semanas para tener una vista a nivel de release.