Sprint en desarrollo móvil: esencia, duración y planificación

¿Qué es un sprint en desarrollo?

Sprint es un timebox de duración fija al final del cual el equipo entrega un incremento del producto listo para usar. El concepto de sprint es la base de Scrum, pero también se utiliza en otros marcos Agile. En el desarrollo móvil, un incremento es un build de la aplicación que se puede instalar en un dispositivo, probar y mostrar a los stakeholders. Un sprint no se puede extender — si las tareas no se completan, se trasladan al siguiente sprint.

La característica clave de un sprint es la duración fija. El equipo no cambia el objetivo del sprint después de la aprobación. Esto proporciona previsibilidad: los stakeholders saben cuándo recibirán el resultado. Dentro del sprint, el equipo decide cómo distribuir el trabajo. El Scrum Master protege al equipo de interferencias externas — no se agregan nuevas tareas al sprint actual. Según la Scrum Guide 2025, esta es la única manera de mantener un ritmo de desarrollo sostenible.

Un sprint consta de cuatro eventos obligatorios: Sprint Planning, Daily Scrum (sincronización diaria), Sprint Review (demostración del resultado), Sprint Retrospective (análisis del proceso). Entre ellos está el trabajo principal: implementación de tareas, pruebas, code review. Duración de cada evento es directamente proporcional a la longitud del sprint: para un sprint de 2 semanas, Planning dura 4 horas, Review 2 horas, Retro 1.5 horas, Daily 15 minutos. En total, los rituales toman alrededor de 8 horas por sprint — el 10% del tiempo de trabajo del equipo.

Rituales Scrum del sprint

Rituales Scrum (ceremonias/eventos) son reuniones estructuradas del equipo dentro del sprint. Sprint Planning al inicio, Daily Scrum cada día, Sprint Review y Retrospective al final. Todos los eventos tienen un timebox. El Scrum Master garantiza el cumplimiento del timebox y el enfoque. Todo el equipo Scrum participa en cada ritual: Product Owner, Scrum Master, desarrolladores. La excepción es Daily Scrum (solo participan los desarrolladores, PO y SM son opcionales).

La conexión de los rituales con las etapas del sprint: Planning establece la dirección (qué y cómo lo hacemos), Daily sincroniza (quién hace qué, qué bloqueadores hay), Review muestra el resultado (qué se hizo, qué no), Retrospective mejora el proceso (cómo hacer mejor el próximo sprint). Saltarse la retrospectiva es el error más común del equipo: cuando los plazos son ajustados, Retro es lo primero que se sacrifica. Esto lleva al estancamiento de los procesos y a la repetición de los mismos errores. La investigación de Scrum.org (2025) muestra que los equipos que realizan Retro cada 2 semanas mejoran la velocidad un 35% más rápido.

Sprint Planning: planificación de la iteración

Sprint Planning es una reunión del equipo al comienzo del sprint donde se determina qué se hará y cómo. El Product Owner presenta las tareas prioritarias del Product Backlog. El equipo estima la capacidad (tiempo disponible considerando vacaciones, reuniones, deuda técnica) y selecciona las tareas que puede completar durante el sprint. El resultado de Planning es el Sprint Goal (objetivo del sprint) y el Sprint Backlog (lista de tareas). El Sprint Goal se formula como una oración corta: “Implementar la pantalla de pedido y la integración de pago mediante SBP.”

Velocity es la velocidad del equipo medida en story points por sprint. Promedio de los últimos 3-5 sprints. Según Scrum.org (2025), un equipo de 5 desarrolladores móviles (3 Android + 2 iOS) tiene una velocity de 25-40 SP por sprint de 2 semanas. Planning usa la velocity como límite superior — toman un 10-15% menos para tener en cuenta tareas imprevistas (code review, incidentes, ayuda a otros equipos). Capacity vs Velocity: capacity son “horas-persona”, velocity son “story points”. Capacity considera vacaciones, bajas por enfermedad, reuniones. La tasa de pérdida típica es del 25-30% del tiempo de trabajo dedicado a actividades no relacionadas con el código.

Planning se divide en dos partes: “qué” (PO describe las tareas, el equipo aclara) — 2 horas, y “cómo” (el equipo descompone y estima) — 2 horas. Para proyectos móviles, en “cómo” se discute: compatibilidad con versiones de Android/iOS, necesidad de feature flags, impacto en el tamaño del APK/IPA, nuevos permisos. Técnica Planning Poker se utiliza para la estimación: cada desarrollador da su estimación en story points (1, 2, 3, 5, 8, 13). Una discrepancia de más de 2 unidades desencadena una discusión de razones. Esto revela riesgos ocultos en la etapa de planificación, no en medio del sprint.

Ejecución del sprint: Daily Standup y seguimiento

Daily Scrum (Standup) es una reunión diaria de 15 minutos para la sincronización del equipo. Cada participante responde tres preguntas: “¿Qué se hizo ayer?”, “¿Qué planeo hacer hoy?”, “¿Qué bloqueadores tengo?”. Daily no es un informe de estado para el manager, sino una herramienta de autoorganización del equipo. Si durante el Daily resulta que dos desarrolladores están trabajando en la misma tarea — es una señal de reorganización. Importante: Daily no resuelve problemas, los identifica — para resolverlos se convoca una reunión separada después de Daily.

Scrum Board (tablero del sprint) es una visualización del Sprint Backlog. Columnas: To Do / In Progress / In Review / Done. Cada tarea se mueve por el tablero. Burndown Chart es un gráfico del trabajo restante por día del sprint. El burndown ideal es una línea recta desde SP total hasta 0. El burndown real es un gráfico escalonado que refleja el cierre de tareas. Un burndown por debajo de la línea ideal significa que vamos retrasados. Señal de problema: si a mitad del sprint se ha completado menos del 30% de las tareas — se necesita ajuste. Es posible que no se hayan considerado los riesgos o que las tareas estuvieran sobreestimadas.

Para el desarrollo móvil, el seguimiento del sprint se ve afectado por factores específicos: tiempo de compilación (el build de Android en CI puede tomar 30+ minutos), espera de moderación de App Store / Google Play (si se necesita lanzar un build a testers a través de TestFlight), compatibilidad con diferentes dispositivos (probar en 10+ modelos lleva tiempo). Consejo: reserve 1 día de buffer al final del sprint para pruebas finales y compilación del build de lanzamiento. Esto reduce el riesgo de un sprint incompleto en un 40% según Mind the Product (2025).

Sprint Review y Retrospective

Sprint Review es una demostración del incremento a los stakeholders. El equipo muestra un build funcional de la aplicación, no diapositivas. La duración es de 2 horas para un sprint de 2 semanas. El Product Owner verifica el cumplimiento de los Acceptance Criteria. Los stakeholders proporcionan feedback que puede afectar al Product Backlog. Review no es un informe, sino un diálogo: los stakeholders pueden hacer preguntas y sugerir cambios. Regla clave: Sprint Review trata sobre el producto, no sobre el proceso. Muestra lo que se logró, no cómo se hizo.

Sprint Retrospective es una reunión interna del equipo para analizar el sprint pasado. Formato: Start Doing (qué empezar a hacer), Stop Doing (qué dejar de hacer), Continue Doing (qué continuar haciendo). La duración es de 1.5 horas para un sprint de 2 semanas. Retrospective es un espacio seguro para discutir problemas. Regla: en Retro no se discuten detalles técnicos (para eso están las reuniones técnicas). Solo proceso, comunicación, herramientas, cultura. El Scrum Master facilita la reunión y se asegura de que cada participante hable.

El resultado de Retrospective son 1-3 mejoras para el próximo sprint. Si el equipo identificó el problema “El code review toma demasiado tiempo” — action item: “Establecer SLA para revisión — 4 horas. Si la revisión no se realiza a tiempo — el desarrollador lo recuerda en Slack.” Action Items deben ser específicos, medibles y asignados a una persona concreta. Según Atlassian (2025), los equipos que cumplen sus action items de Retro mejoran la velocidad en un 15-25% en 3-4 sprints. Los que no lo hacen, se estancan.

Cómo elegir la duración del sprint

2 semanas es el estándar para el desarrollo móvil. El equilibrio óptimo entre previsibilidad y flexibilidad. Tiempo suficiente para: planificar, implementar 3-5 funcionalidades medianas, probar, mostrar resultados. 1 semana es para equipos con alta madurez de procesos y CI/CD. Requiere decisiones rápidas, mínima burocracia. Adecuado para startups en etapa temprana que necesitan experimentar rápidamente. Desventaja: alta sobrecarga de rituales (Planning + Review + Retro cada semana = 7.5 horas).

3-4 semanas son para proyectos complejos que implican integración con hardware (wearables, IoT, dispositivos BLE), moderación larga de las tiendas o migraciones importantes (por ejemplo, transición de RxJava a Coroutines). Los sprints largos proporcionan más tiempo para pruebas pero aumentan el riesgo del “efecto cascada” — el equipo pierde flexibilidad Agile. Recomendación de la Scrum Guide: no superar 1 mes. Si el sprint es más largo, habrá demasiado contexto en Review y los stakeholders no podrán dar feedback de calidad.

Problemas típicos de los sprints

Problema 1: Scope Creep. A mitad del sprint, el Product Owner agrega una nueva tarea “urgente e importante”. El equipo acepta — y el sprint fracasa. Solución: el Sprint Goal es un contrato. Cualquier cambio requiere revisar el Sprint Goal, lo que solo es posible en casos de emergencia. La nueva tarea va al Product Backlog y al siguiente sprint. Si la tarea es realmente crítica — se cancela el Sprint Goal anterior, se replanifica el sprint, pero esto es una excepción, no una práctica. La frecuencia de scope creep superior a una vez cada 3 sprints es señal de un Product Owner débil.

Problema 2: Tareas incompletas. Al final del sprint, el 50% de las tareas están In Progress, el 20% In Review, solo el 30% Done. Razones: capacidad sobreestimada, complejidad subestimada, bugs no planificados. Solución: analice la razón en Retro. Si sistemáticamente no se llega — no aumente la cantidad de tareas en Planning, disminúyalas. Los equipos que toman un 20% menos de tareas muestran una tasa de finalización más alta (80%+ frente a 50-60%). Lista de verificación para Planning: para cada tarea, verificar Acceptance Criteria, Definition of Ready y dependencia con otras tareas.

Problema 3: Retro formal. El equipo realiza Retro solo por cumplir — 15 minutos, frases genéricas, sin action items. Solución: cambie el formato de cada Retro. Métodos: Sailboat (qué frena, qué acelera), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Asigne action items con plazos y responsables. Al comienzo de la siguiente Retro, verifique el cumplimiento de los action items anteriores. Según Atlassian (2025), los equipos que usan diferentes formatos de Retro generan un 50% más de información útil.