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.
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. Un sprint sin demo es solo una fecha límite; un sprint sin retro es una cinta de correr.
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.
Ejemplo del fallo silencioso: un equipo corre «sprints» de dos semanas durante seis meses, acude a cada reunión de planificación y no envía nada en lo que un stakeholder pueda hacer clic. El consejo se sigue deslizando porque el trabajo se dimensiona por esperanza, no por lo que cabe, y no hay revisión que obligue al equipo a enfrentarse a un incremento funcional. El arreglo es brutal y simple: al final de cada sprint, alguien fuera del equipo tiene que poder usar lo construido. Si no puede, el ritmo es teatro, y encoger a sprints de una semana suele exponer por qué en una quincena.
El trade-off honesto y el error de founder más común: tratar los sprints como una forma de cumplir una fecha externa fija. El ritmo se construye en torno a fijar la caja de tiempo y flexibilizar el alcance, que es lo contrario de una fecha de lanzamiento dura con alcance fijo. Para trabajo genuinamente guiado por fecha y de alcance fijo quieres un plan a precio fijo con milestones explícitos de SDLC, no un sprint board. Los sprints encajan con la entrega agile continua y el trabajo iterativo hacia un MVP; encajan mal con investigación y diseño, donde una exploración con caja de tiempo y un resumen escrito supera a una demo forzada. También dependen de que el CI/CD esté sano, porque un sprint que no puede enviar al final no es un sprint.