Cómo es un sprint de Scrum día por día: planning, daily, review y retro en un equipo de producto real

Resumen ejecutivo

• Un sprint es un ciclo de trabajo de duración fija (en este ejemplo, dos semanas) en el que un equipo se compromete a entregar un incremento de producto que funcione.

• Tiene cuatro eventos: sprint planning, daily scrum, sprint review y retrospectiva. Cada uno responde una pregunta distinta.

• Te contamos el sprint día por día en un equipo de producto real: qué se decide, cómo se mueve el tablero y qué pasa cuando entra un pedido urgente.

• Al final, los errores más comunes que convierten un sprint en una lista de tareas sin foco.

La teoría de Scrum cabe en pocas páginas, pero lo que cuesta es imaginar cómo se ve en un equipo de verdad. Ya explicamos qué es la metodología Agile y las diferencias entre Scrum Master y Product Owner. Acá vamos a lo práctico: seguimos a un equipo de producto ficticio durante un sprint de dos semanas, desde la planning del lunes hasta la retrospectiva del viernes siguiente. Todo lo que pasa está basado en la Guía de Scrum oficial, aterrizado en situaciones cotidianas.

El equipo y el objetivo

El equipo trabaja en la app de una tienda online. Lo forman una Product Owner, un Scrum Master, tres desarrolladores, una diseñadora UX y una persona de QA. El sprint dura dos semanas, de lunes a viernes de la semana siguiente.

El Product Backlog, la lista priorizada de todo lo que podría hacerse en el producto, ya está ordenado por la Product Owner. Arriba de todo hay un problema claro: muchos usuarios abandonan el carrito en el paso de envío.

Día 1 (lunes): sprint planning

La planning es la reunión que abre el sprint. La Guía de Scrum la limita a un máximo de ocho horas para un sprint de un mes; para dos semanas, el equipo la resuelve en unas tres o cuatro horas. Responde tres preguntas:

• ¿Por qué es valioso este sprint? El equipo define el objetivo del sprint: «Reducir el abandono en el paso de envío mostrando el costo antes del checkout».

• ¿Qué se puede hacer? Eligen del backlog las historias que aportan a ese objetivo: calculadora de envío en el carrito, mensaje de envío gratis a partir de cierto monto y un evento de analítica para medir el cambio.

• ¿Cómo se va a hacer? Los desarrolladores parten cada historia en tareas de un día o menos y las cargan en el tablero.

Atlassian tiene una buena guía de sprint planning con plantillas si querés armar la tuya.

Días 2 a 4: las primeras dailies

Cada mañana, a la misma hora, el equipo hace la daily scrum: quince minutos de pie, frente al tablero. No es un reporte al jefe; es una reunión de los desarrolladores para revisar el avance hacia el objetivo y ajustar el plan del día.

En lugar de la ronda clásica de «qué hice ayer, qué hago hoy», este equipo recorre el tablero de derecha a izquierda: primero lo que está por terminarse, después lo que está bloqueado y al final lo que no arrancó. Así el foco está en terminar, no en empezar cosas nuevas.

El martes aparece el primer bloqueo: la API de la empresa de envíos no devuelve precios para algunos códigos postales. El Scrum Master se encarga de conseguir una reunión con el proveedor para que el equipo pueda seguir trabajando.

Día 5 (viernes): refinamiento del backlog

A mitad de sprint, la Product Owner y parte del equipo dedican una hora a refinar el backlog: aclaran las historias del próximo sprint, agregan criterios de aceptación y hacen una estimación rápida. El refinamiento no es un evento formal de Scrum, pero casi todos los equipos lo hacen para que la próxima planning sea más corta.

Día 6 (lunes): entra un pedido urgente

El área comercial pide, con urgencia, un banner para una promoción que arranca en tres días. ¿Qué hace el equipo?

• La Product Owner evalúa si el pedido pone en riesgo el objetivo del sprint.

• Como es chico y no afecta el objetivo, lo negocia con los desarrolladores: entra el banner y sale del sprint la tarea menos prioritaria, que vuelve al backlog.

• Si el pedido hubiera vuelto obsoleto el objetivo, la Product Owner podría cancelar el sprint, algo que la guía permite pero que es excepcional.

La regla práctica: el alcance se puede renegociar, el objetivo del sprint se protege.

Días 7 a 9: cerrar y testear

En la segunda semana el tablero cambia de forma: menos tarjetas en «por hacer» y más en «en revisión» y «testing». La persona de QA prueba cada historia contra sus criterios de aceptación y la diseñadora revisa que la implementación respete los diseños.

Acá aparece la definición de terminado (Definition of Done): una historia no está lista si no tiene código revisado, pruebas pasadas y el evento de analítica funcionando. Si algo no cumple la definición, no se muestra en la review.

Día 10 (viernes): sprint review y retrospectiva

Sprint review

El equipo muestra el incremento funcionando a las personas interesadas: comercial, atención al cliente y el líder de producto. No es una presentación con diapositivas; es una demo del carrito con la calculadora de envío. Los participantes comentan, y la Product Owner ajusta el backlog con lo que surge. Por ejemplo, atención al cliente pide mostrar también los tiempos de entrega.

Retrospectiva

Después, solo el equipo Scrum hace la retrospectiva: qué salió bien, qué no y qué van a cambiar en el próximo sprint. Esta vez, la conclusión es que el bloqueo con la API se detectó tarde. Deciden que, para integraciones externas, van a hacer una prueba técnica antes de la planning. Si buscás dinámicas para esta reunión, las plantillas de retrospectiva de Atlassian son un buen punto de partida.

Errores comunes en un sprint

• Un sprint sin objetivo. Si el sprint es solo una lista de tareas, cualquier pedido urgente lo desarma.

• La daily como reunión de estado. Si dura media hora y cada uno le habla al Scrum Master, dejó de servir.

• Historias demasiado grandes. Si una historia no entra en el sprint, hay que partirla en el refinamiento.

• Saltarse la retrospectiva. Es el único espacio para mejorar cómo trabaja el equipo; sin ella, los mismos problemas se repiten.

• Mostrar trabajo sin terminar en la review. Lo que no cumple la definición de terminado vuelve al backlog.

Si en tu equipo Scrum no termina de encajar, compará con Kanban en nuestra guía de Scrum vs Kanban.

Cursos recomendados de Coderhouse

Para aplicar Scrum con práctica y casos reales, el curso de Scrum y Metodologías Ágiles te prepara para trabajar en un equipo ágil desde el primer día. Si lo que te atrae es el rol que prioriza el backlog y define el objetivo de cada sprint, mirá el curso de Product Manager.

Preguntas frecuentes

¿Cuánto dura un sprint de Scrum? Un mes o menos. La mayoría de los equipos de producto trabaja con sprints de una o dos semanas, porque permiten recibir feedback más seguido.

¿Qué pasa si no se termina todo lo planificado? Lo que no está terminado vuelve al backlog y la Product Owner decide si entra en el próximo sprint. En la retrospectiva conviene analizar por qué pasó.

¿La daily tiene que ser presencial? No. Muchos equipos remotos la hacen por videollamada con el tablero compartido en pantalla. Lo importante es que sea corta, a la misma hora y enfocada en el objetivo.

¿Quién participa en la retrospectiva? El equipo Scrum completo: Product Owner, Scrum Master y desarrolladores. Las personas externas participan en la review, no en la retrospectiva.