ENGAGEMENT

Sprint

Unidad de trabajo de duración fija (normalmente 1 a 2 semanas) al final de la cual se entrega y revisa un incremento enviable.

Última revisión: 2026-05-24 porKevin Riedl wiki ↗

Sprint es un término específico de Scrum que se ha colado en el habla general para nombrar cualquier unidad de trabajo corta y acotada. La definición original exige tres cosas: duración fija, sesión de planificación al inicio y revisión al final. La mayoría de equipos conservan las dos primeras y abandonan la tercera, por eso muchos llaman „sprints" a su ritmo pero no producen incremento demostrable.

La duración importa. Sprints de una semana fuerzan un alcance estrecho y sacan rápido a la luz los problemas de entrega. Sprints de dos semanas dan espacio para trabajo sustancial pero absorben más deriva. Sprints de tres semanas casi siempre acaban siendo dos mal planificados.

// FAQ

Preguntas frecuentes

Preguntas frecuentes

Una si quieres exponer cuellos de botella rápido y forzar alcance pequeño. Dos si el dominio exige bloques de trabajo más sustanciosos. Tres semanas es casi siempre un sprint de dos mal planificado. Cuatro semanas no es sprint, es un mini-milestone disfrazado.
Porque mantienen la planificación y abandonan la revisión. Sin demo del incremento al final del sprint, no hay feedback loop. Sin feedback, el sprint es solo una semana o dos de cascada con un standup. La revisión es la parte cara y la primera que se cae cuando aprieta el calendario.
No. Un README, un Trello o una hoja de cálculo bastan si el equipo es pequeño. Lo que importa es el ciclo plan-build-demo, no la herramienta. Equipos que se obsesionan con elegir entre Jira y Linear suelen tener un problema de proceso, no de tooling.