El Sprint

Los Sprint son eventos de duración fija de un mes o menos para crear una cadencia de entrega y retroalimentación consistente para el Equipo Scrum. Cuanto más corta sea la duración del Sprint, más rápido será el bucle de retroalimentación. Por ejemplo, Scrum Inc. trabaja en Sprints de una semana.

El Sprint es un contenedor de todos los demás eventos. Un nuevo Sprint comienza inmediatamente después de la conclusión del sprint anterior, y cada Sprint normalmente comienza con la Planificación del Sprint y termina con la Revisión del Sprint & Retrospectiva del Sprint. Durante cada día del Sprint, hay un breve evento llamado Scrum Diario que sirve para mantener al equipo alineado y para descubrir los impedimentos que el equipo encuentra relacionados con el progreso del Sprint Backlog. Todo el trabajo y los eventos necesarios para lograr el Objetivo del Sprint, incluyendo la Planificación del Sprint, los Scrums Diarios, la Revisión del Sprint y la Retrospectiva del Sprint, ocurren dentro de los Sprints.

El ciclo regular del Sprint sirve para:

• Enfocar la entrega en el Objetivo del Sprint. Cada Sprint el equipo debe desarrollar un incremento potencialmente despachable de software, una iteración utilizable de un producto de hardware, o en última instancia: un valor distinto para el cliente.
• Dar al Equipo retroalimentación regular y de alta calidad del cliente sobre el valor entregado. El Equipo puede entonces inspeccionar y adaptar tanto su proceso como su producto basándose en la información real y procesable del cliente.
• Medir la producción del Equipo durante un período consistente y recurrente. Esta medición de la producción se denomina velocidad del equipo. El equipo puede utilizar la velocidad para prever su capacidad de entregar el trabajo a lo largo del tiempo, y crear planes de sprint realistas basados en datos históricos.

Los sprint permiten la previsibilidad asegurando la inspección y la adaptación del progreso hacia el objetivo del producto al menos cada mes natural. Los Sprints más cortos pueden generar más ciclos de aprendizaje y limitar el riesgo de coste y esfuerzo a un marco temporal más pequeño. Cuando el horizonte de un Sprint es demasiado largo, el Objetivo del Sprint puede perder validez, la complejidad puede aumentar y el riesgo puede incrementarse. Cada sprint puede ser considerado un proyecto corto y puede ser cancelado si el Objetivo del Sprint se vuelve obsoleto. Sólo el Product Owner tiene la autoridad para cancelar el sprint.