Planear y ejecutar un Sprint significa tomar los elementos más prioritarios del Product Backlog, comprometerse a terminarlos en dos semanas y entregar trabajo real al final.
El lunes que cambió todo en el equipo de Liverpool
Era un lunes por la mañana en las oficinas de Liverpool en Polanco. Valeria, desarrolladora con tres años de experiencia, llegó a la sala de juntas con una taza de café y una pregunta sin respuesta: ¿por dónde empezamos? El equipo tenía un backlog con 47 historias de usuario, un Product Owner impaciente y cero claridad sobre qué hacer primero.
Ese momento de confusión es más común de lo que parece. Según el Scrum Alliance, el 68% de los equipos que empiezan con Scrum reportan que su mayor dificultad no es la tecnología, sino la ceremonia de planeación. No saben cuánto trabajo tomar, cómo estimarlo ni cómo organizarse para los próximos 14 días.
La solución está en entender que un Sprint no empieza con código. Empieza con una conversación muy específica.
La Sprint Planning: la reunión que define el éxito
La Sprint Planning es la ceremonia donde el equipo decide qué va a construir y cómo lo va a construir. Tiene dos partes distintas y las dos son obligatorias.
En la primera parte, el Product Owner presenta los elementos más prioritarios del Product Backlog. El equipo hace preguntas, aclara dudas y decide cuánto trabajo puede completar en el Sprint. Esta decisión se basa en la velocidad histórica del equipo, no en promesas optimistas.
En la segunda parte, el equipo descompone cada historia de usuario en tareas técnicas concretas. Una historia de usuario como "el usuario puede filtrar productos por precio" se convierte en tareas como: diseñar el componente de filtro, conectar el endpoint del API, escribir pruebas unitarias y hacer revisión de código. Cada tarea debe poder completarse en menos de un día.
Al final de la Sprint Planning, el equipo tiene un Sprint Goal claro. El Sprint Goal es una frase corta que describe el valor que va a entregar ese Sprint. Por ejemplo: "El usuario puede buscar y filtrar productos en el catálogo móvil." Ese objetivo guía todas las decisiones durante los 14 días siguientes.
¿Cómo estimar sin adivinar?
Aquí es donde muchos equipos se pierden. Estimar no significa predecir el futuro. Significa comparar el esfuerzo relativo entre tareas.
La técnica más usada en equipos ágiles mexicanos es el Planning Poker. Funciona así: cada miembro del equipo tiene cartas con los números de la secuencia de Fibonacci: 1, 2, 3, 5, 8, 13 y 21. El equipo discute una historia de usuario y cada persona elige una carta en secreto. Todos revelan sus cartas al mismo tiempo.
Si alguien pone 3 y otro pone 13, hay una conversación. La persona que puso 13 explica qué riesgos o complejidades vio que los demás no consideraron. Esa conversación es el verdadero valor del Planning Poker: fuerza al equipo a alinear su comprensión del trabajo.
Los números no son horas. Son Story Points, unidades abstractas de esfuerzo relativo. Un equipo de desarrollo de software en una empresa como FEMSA Digital puede tener una velocidad de 30 Story Points por Sprint. Eso significa que en cada Sprint de dos semanas completan historias que suman 30 puntos. Si el Product Owner quiere incluir una historia de 8 puntos en un Sprint que ya tiene 28 puntos asignados, el equipo puede decir con datos que no cabe.
Este sistema elimina las negociaciones basadas en opiniones. Los números hablan.
Los 14 días: cómo se ve un Sprint por dentro
Una vez que termina la Sprint Planning, empieza el trabajo real. Y aquí es donde el Daily Scrum se convierte en la herramienta más poderosa del equipo.
Cada día, el equipo se reúne durante exactamente 15 minutos. No más. No es una reunión de reporte para el jefe. Es una sincronización entre compañeros. Cada persona responde tres preguntas simples: ¿qué hice ayer?, ¿qué voy a hacer hoy?, ¿hay algo que me está bloqueando?
Imagina que Carlos, desarrollador backend en Bimbo Digital, dice en su Daily: "Ayer terminé la integración con el API del proveedor. Hoy voy a trabajar en la validación de datos. Estoy bloqueado porque no tengo acceso al ambiente de pruebas." El Scrum Master escucha ese bloqueo y ese mismo día gestiona el acceso. El trabajo no se detiene por 48 horas esperando un correo.
Ese es el poder del Daily: detecta problemas en 15 minutos en lugar de descubrirlos en la última semana del Sprint.
Durante los 14 días, el equipo actualiza el Sprint Backlog cada día. Las tareas se mueven de "Por hacer" a "En progreso" a "Terminada". Un tablero Kanban visible para todos, ya sea físico en la oficina o digital en una herramienta como Jira o Trello, mantiene al equipo alineado sin necesidad de reuniones extra.
El último día: Sprint Review y Sprint Retrospective
El último día del Sprint tiene dos ceremonias importantes. Muchos equipos las confunden o las combinan. Son diferentes y cumplen funciones distintas.
La Sprint Review es una demostración del trabajo terminado. El equipo invita a los stakeholders, que pueden ser el director de producto, representantes del área comercial o incluso clientes. Se presenta el Incremento funcional. No slides. No mockups. Software que funciona.
En una empresa como Mercado Libre, esto podría verse así: el equipo muestra en vivo la nueva función de comparación de precios en la app. Los stakeholders la usan, hacen preguntas y dan retroalimentación. El Product Owner toma nota y actualiza el Product Backlog con base en esa conversación. La Sprint Review no es un examen. Es una colaboración.
La Sprint Retrospective ocurre después de la Review y es privada para el equipo Scrum. Aquí no hay stakeholders externos. El equipo responde tres preguntas: ¿qué salió bien?, ¿qué salió mal?, ¿qué vamos a mejorar en el próximo Sprint?
Un equipo maduro no tarda más de 90 minutos en esta ceremonia. Y siempre termina con al menos un compromiso concreto de mejora. No una lista de quejas. Un cambio de proceso específico que van a implementar la próxima semana.
El regreso a Polanco
Valeria y su equipo en Liverpool completaron su primer Sprint bien planeado. Tomaron 28 Story Points de trabajo, definieron un Sprint Goal claro y entregaron una función de búsqueda mejorada en la app. En la Sprint Review, el director de producto pudo ver la función funcionando en su teléfono.
No fue perfecto. En la Retrospective descubrieron que tardaban demasiado en hacer code reviews. Decidieron que a partir del siguiente Sprint, toda revisión de código debía completarse en menos de 4 horas. Ese cambio, pequeño y concreto, redujo su tiempo de ciclo en un 30% durante el Sprint siguiente.
Eso es Scrum en acción. No es una metodología de libro. Es un sistema de aprendizaje continuo que mejora Sprint a Sprint, equipo a equipo, empresa a empresa.
El siguiente Sprint de Valeria empezó el lunes siguiente, a las 9 de la mañana, con una taza de café y sin ninguna pregunta sin respuesta.