Yo también soy partidario de los sprints cortos: se tarda menos en conseguir un feedback efectivo sobre una versión del producto en producción y se reduce el tiempo medio de espera en la pila de producto de una historia de usuario urgente que no ha entrado en el sprint.
No soy partidario de sprints largos.
¿Cómo corto debe ser el sprint? No tengo la respuesta porque la tienes que encontrar tú en base a tu proyecto y tu contexto.
Un condicionante importante es la capacidad de aguantar el ritmo porque no solo se trata de adecuar la cantidad del trabajo a la velocidad, algo que se consigue en el momento en que todo el mundo (sobre todo el área usuaria o el product owner) está mentalizado en que es la mejor forma de trabajar y se acierta en las estimaciones (importantísimo), sino de tener en cuenta que además hay que ir preparando el siguiente sprint mediante el refinamiento de la pila de producto, que no es otra cosa que obtener el nivel de detalle suficiente en una historia de usuario para poder valorarse de manera adecuada y poder ejecutarse cuando sea posible, mientras se está pasando a producción la anterior entrega, algo que puede ser muy complicado en organizaciones que compartan un equipo de instalación de aplicaciones que esté fuertemente procedimientado, teniendo en cuenta, además, que hay que trabajar de manera priorizada con las incidencias que vayan saliendo.
Es posible que algunas de esas tareas que tienen dependencias externas, como el refinamiento de la pila o el paso a producción se retrase, lo cual hace necesario un mayor esfuerzo para tratar de mitigar en lo posible la desviación, lo que produce un fuerte desgaste cuando esta situación se hace reiterada en los sprints.
Un día, un amigo me preguntó: «¿por qué se le llaman sprints a las iteraciones?», poco después por sí mismo pudo conocer la respuesta.
Jummp 