'El mayor sinsentido de este sector': el desarrollo de software cada vez recurre más a los 'sprints', pero tienen un lado negativo

En muchas empresas tecnológicas —y cada vez más en otros sectores— se organiza el trabajo en "sprints": períodos de tiempo cortos y fijos (normalmente dos semanas) en los que un equipo se compromete a terminar un conjunto concreto de tareas o proyectos.

En teoría, esto da ritmo y claridad. Pero Daniel Blanco, ingeniero de software español que trabaja en MongoDB, ha cosechado ya casi 1000 'likes' mostrando una opinión bastante crítica con esta metodología:

"Dividir el trabajo en sprints es el mayor sinsentido de este sector. [...] Me parece increíble que esto sea el "estándar" de la industria".

Y es que, en la práctica, los 'sprints' no siempre funcionan como se espera:

• Si el trabajo resulta más rápido de lo previsto, se tiende a añadir tareas para "llenar" el sprint.
• Si el trabajo se alarga, se corre para acabar, sacrificando a veces la calidad.

El resultado puede ser que el objetivo no sea entregar valor de la mejor manera, sino cumplir con el calendario.

El problema de fondo con los 'sprints'

1) Incentivos perversos

Si el 'sprint' es de dos semanas y terminas en semana y media, es común añadir tareas nuevas "para aprovechar el tiempo". En sentido contrario, si vas retrasado, puedes sentir la presión de acabar deprisa aunque eso implique bajar la calidad. Esto es lo que se llama ley de Parkinson: el trabajo se expande (o se contrae) para llenar el tiempo disponible.

2) Estimación como fin en sí mismo

En Scrum (un marco que usa sprints) se emplean técnicas como los 'story points' para estimar el esfuerzo de cada tarea. El equipo planifica el sprint en función de su velocidad (puntos que suele completar). Pero, si las estimaciones no aciertan, se gasta mucho tiempo ajustando el sistema en lugar de mejorar cómo se divide y entrega el trabajo.

3) Coste de coordinación

Los sprints suelen implicar varias reuniones fijas:

• Planificación: decidir qué entra en el sprint.
• Reuniones diarias (dailies): actualizar al equipo.
• Revisión: mostrar lo hecho.
• Retrospectiva: analizar cómo mejorar.

Esto aporta orden, pero puede comerse horas productivas, sobre todo en equipos grandes.

4) Duración arbitraria

Dos semanas no siempre son el tamaño "natural" del trabajo. Hay tareas que duran un día y otras que requieren un mes. El marco del sprint puede forzar a fraccionar artificialmente o retrasar entregas.

Señales de que los 'sprints' no te están ayudando

Los sprints pueden ser útiles, pero si observas una o varias de estas señales de forma recurrente, quizá estén creando más obstáculos que valor:

1. Relleno artificial de tareas

• Qué pasa: como hablábamos antes al mencionar los incentivos perversos, puede ocurrir que el trabajo se termine antes de que acabe el sprint, o que se añadan tareas menores o poco prioritarias solo para "aprovechar el tiempo".
• Por qué es mala señal: el equipo dedica esfuerzo a cosas que no aportan valor real, en lugar de invertir ese tiempo en mejorar procesos, explorar ideas o ayudar a otros.
• Ejemplo: el jueves de la segunda semana, con todo entregado, se decide "meter" una mejora estética que no estaba planificada, solo para no estar "sin nada que hacer".

2. Reuniones diarias largas y sin foco

• Qué pasa: las dailies, que deberían durar 10–15 minutos, se convierten en reuniones de media hora o más, llenas de detalles irrelevantes para parte del equipo.
• Por qué es mala señal: indica que se está usando la reunión como “miniplanning” o sesión de resolución de problemas, en lugar de un breve punto de sincronización.
• Ejemplo: cada miembro da un discurso detallado sobre su día, aunque el 80% no afecte al resto.

3. Trabajo arrastrado de un sprint a otro (rollovers crónicos)

• Qué pasa: tareas que se planifican para un sprint no se terminan y se vuelven a incluir en el siguiente… y en el siguiente.
• Por qué es mala señal: puede indicar que las tareas están mal dimensionadas, que hay interrupciones constantes o que se sobreestima la capacidad del equipo.
• Ejemplo: una funcionalidad lleva planificada tres sprints seguidos... y sigue sin entregarse.

4. Cumplimiento de "velocidad" pero sin impacto visible

• Qué pasa: el equipo completa la cantidad de puntos o tareas planificadas, pero el cliente o usuario no percibe mejoras significativas.
• Por qué es mala señal: la métrica interna (puntos) se está cumpliendo, pero no se traduce en valor tangible para el negocio o el usuario final.
• Ejemplo: se terminan muchas tareas técnicas internas, pero ninguna funcionalidad nueva llega al mercado en meses.

5. Ansiedad de calendario

• Qué pasa: las decisiones se toman en función de la fecha de fin del sprint, no de la urgencia o valor real del trabajo.
• Por qué es mala señal: se prioriza el "cumplir con el sprint" sobre hacer lo correcto en el momento adecuado.
• Ejemplo: se pospone una corrección crítica porque "rompería la planificación del sprint", aunque afecte a clientes importantes.

6. Baja moral del equipo

• Qué pasa: las personas sienten que trabajan contra un reloj que siempre corre en su contra, o que los objetivos cambian a mitad del sprint de forma recurrente.
• Por qué es mala señal: la presión constante y la falta de control sobre las prioridades llevan al desgaste, lo que impacta en la motivación y en la calidad del trabajo.
• Ejemplo: comentarios recurrentes como "otro sprint que no cerramos a tiempo" o"para qué planificamos si siempre cambia".

Cuándo sí tienen sentido los sprints

Aunque los sprints no son la única forma de organizar el trabajo, en ciertos contextos aportan beneficios claros:

1. Entornos regulados o con validaciones externas

En sectores como banca, sanidad o aeronáutica, a menudo es necesario coordinar entregas con auditorías, homologaciones o ventanas de publicación definidas por terceros. Un sprint fijo permite alinear las entregas con esos hitos y asegurar que todo el equipo trabaja con la misma referencia temporal.

2. Equipos en fase de aprendizaje o maduración

Para equipos con poca experiencia en autogestión, la estructura de reuniones y objetivos cortos puede servir como entrenamiento en disciplina, estimación y priorización. La cadencia regular ayuda a crear hábitos, como revisar lo hecho, ajustar procesos y reflexionar sobre mejoras.

3. Proyectos con hitos inamovibles

Campañas de marketing, lanzamientos de producto, ferias o conferencias con fecha cerrada se benefician de una planificación por bloques cortos que aseguren avances medibles en cada ciclo. El sprint actúa como un "checkpoint" intermedio para detectar retrasos con tiempo para corregir.

4. Necesidad de sincronizar con otros equipos o áreas

Si un equipo depende de entregas o validaciones de otro (por ejemplo, desarrollo y diseño, o desarrollo y QA externo), una cadencia común facilita la coordinación. Esto reduce el riesgo de que un equipo trabaje mucho tiempo en algo que luego se bloquee esperando a otro.

Métricas que sí importan

Cuando se trabaja con sprints u otros métodos ágiles, es fácil caer en la trampa de medir lo que es cómodo pero no necesariamente útil, como los "puntos de historia" o la "velocidad" del equipo. Estas cifras pueden ser interesantes para coordinar internamente, pero no siempre reflejan lo que de verdad importa: si estamos entregando valor a buen ritmo y con calidad.

'Throughput'

El número de tareas, historias o entregables completados en un periodo (por ejemplo, por semana o por mes), es el dato que te dice cuánta capacidad real tienes para terminar cosas, no solo para empezarlas.

• Ejemplo: si tu equipo completa de media 10 tareas por semana, podrás prever cuánto puedes asumir para el próximo mes sin sobrecargarlo.

'Cycle time'

Es el tiempo desde que alguien empieza a trabajar en una tarea hasta que está terminada y lista para usar: un cycle time corto significa que las ideas o peticiones se convierten en realidad rápidamente.

• Ejemplo: si el cycle time medio es de 4 días, significa que, en condiciones normales, lo que empieces hoy estará listo antes de que acabe la semana.

Edad del 'WIP'

Es la edad de cada tarea que está actualmente "en progreso" (WIP = Work In Progress o "trabajo en curso"); si las tareas empiezan a acumular días sin avanzar, es señal de que hay cuellos de botella o falta de foco.

• Ejemplo: si una tarea lleva 15 días en curso y tu cycle time medio es de 4, probablemente esté atascada y necesite atención inmediata.

Tasa de retrabajo o defecto

Es el número de entregas que necesitan correcciones o rehacerse. Resulta relevante porque hacer mucho trabajo rápido no sirve si la mitad hay que repetirla.

• Ejemplo: si 3 de cada 10 entregas vuelven por errores, quizá sea momento de mejorar las pruebas o la revisión antes de dar algo por terminado.

Lead time de negocio

Es el tiempo total desde que alguien pide algo hasta que lo recibe y puede usarlo. Se trata de la métrica que ven los clientes o usuarios: no les importa cuándo "empezaste", sino cuándo reciben valor.

• Ejemplo: si un cliente pide una funcionalidad el 1 de marzo y se entrega el 15 de abril, el lead time de negocio es de 45 días. Reducir ese tiempo mejora la satisfacción y la competitividad.

Si no puedes dejar los sprints todavía

En muchas organizaciones no es posible cambiar de un día para otro la forma de trabajar. Quizá porque otros equipos usan sprints y hay que coordinarse, porque los procesos internos están montados alrededor de ellos o porque hay resistencia al cambio.

Si es tu caso, no significa que estés condenado a sufrir sus inconvenientes: puedes hacer que los sprints funcionen mejor aplicando algunos ajustes.

• Usa sprints "invisibles": Es decir, mantén la estructura del sprint para coordinar agendas (planificación, revisiones, retrospectivas), pero gestionando las tareas internamente como si trabajases en flujo continuo. Es decir, dentro de cada sprint, utiliza un tablero Kanban con límites de trabajo en curso (WIP) y métricas de flujo. Así, sigues "hablando el mismo idioma" que el resto de la organización, pero mejoras la entrega interna.
• Reduce "ceremonias" a lo esencial: Mantén la reunión diaria corta (máx. 15 minutos) y centrada en desbloquear problemas (no en dar un informe completo), y agrupa la revisión y la retrospectiva en una sola sesión mensual si la frecuencia actual consume demasiado tiempo.
• Ajusta el tamaño de las tareas: Planifica tareas que se puedan completar en pocos días, no en semanas. Esto reduce el riesgo de arrastrar trabajo de un sprint a otro y facilita mostrar resultados parciales.

Imágenes | Marcos Merino mediante IA

En Genbeta | Desde que uso el truco de productividad que recomienda Harvard ya no procrastino ni pierdo tiempo

-
La noticia "El mayor sinsentido de este sector": el desarrollo de software cada vez recurre más a los 'sprints', pero tienen un lado negativo fue publicada originalmente en Genbeta por Marcos Merino .