Plantilla de diagrama de Gantt para sprint planning
Un sprint ágil de 2 semanas visualizado como un Gantt: planificación, reuniones diarias, diseño, desarrollo, revisión de código, QA, demo y retrospectiva — para equipos que quieren ver las fechas y dependencias del sprint en una sola vista.
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
01
Arranque del sprint
Día 1
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
02
Días 2–4 — Diseño e inicio
Días 2–4
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
03
Días 5–8 — Desarrollo
Días 5–8
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
04
Días 9–11 — QA y fusión
Días 9–11
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
05
Días 12–14 — Demo y retrospectiva
Días 12–14
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
01Empieza primero por la historia más grande. Adelanta el riesgo en el sprint, no lo dejes para después.
02Abre cada PR en las 24 horas siguientes a que el trabajo esté listo. Los PR sin abrir son retrasos silenciosos.
03Haz 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.
04Termina cada retrospectiva con un cambio concreto para el próximo sprint. Las listas de 15 ideas no producen ningún cambio.
05Haz 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.
Gantt Chart Maker