SM_T030 Sprint

Plataformas de Aprendizaje Autodirigido

Sprint.

El corazón del Marco de Trabajo Scrum es el Sprint, es un bloque de tiempo de un mes o menos durante el cual se crea un incremento de producto terminado, utilizable y potencialmente desplegable.

Es conveniente que la duración de los Sprints sea consistente a lo largo del esfuerzo de desarrollo; cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint previo.

Los Sprints contienen y consisten de la Reunión de Planificación del Sprint, las Reuniones Diarias, el trabajo de desarrollo, Reunión Revisión del Sprint, y la Reunión Retrospectiva del Sprint.

Durante el Sprint:

  • ​No se realizan cambios que puedan afectar al Objetivo del Sprint.
  • Los objetivos de calidad no disminuyen.
  • El Product Backlog se refina según sea necesario.
  • El alcance puede ser clarificado y renegociado entre el Product Owner y el Development Team a medida que se va aprendiendo más.

​Cada Sprint puede considerarse un proyecto con un horizonte no mayor de un mes. Al igual que los proyectos, los Sprints se usan para lograr algo. Cada Sprint tiene una definición de qué se va a construir, un diseño y un plan flexible que guiará la construcción y el trabajo y el producto resultante.

Están limitados a un mes calendario. Cuando el horizonte de un Sprint es demasiado grande la definición de lo que se está construyendo podría cambiar, la complejidad podría elevarse y el riesgo podría aumentar.

Se pueden emplear Sprints más cortos para generar más ciclos de aprendizaje y limitar el riesgo de costo y esfuerzo a un período de tiempo menor.

Cada Sprint puede considerarse un proyecto corto.

Los Sprints habilitan la predictibilidad, al asegurar la inspección y adaptación del progreso al menos en cada mes calendario. Los Sprints también limitan el riesgo al costo de un mes calendario.

Un Sprint puede ser cancelado antes de que el bloque de tiempo llegue a su fin. Solo el Product Owner tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de los interesados, del Equipo de Desarrollo o del Scrum MasterUn Sprint se cancelaría si el Objetivo del Sprint llega a quedar obsoleto.

Esto podría ocurrir si la compañía cambia la dirección o si las condiciones del mercado o de la tecnología cambian.

En general, un Sprint debería cancelarse si no tuviese sentido seguir con él dadas las circunstancias. Pero debido a la corta duración de los Sprints, rara vez la cancelación tiene sentido.

Cuando se cancela un Sprint, se revisan todos los Elementos del Product Backlog que se hayan completado y terminado.

Si una parte del trabajo es potencialmente entregable, el Product Owner normalmente lo acepta.

Todos los elementos del Product Backlog no completados se vuelven a estimar y se vuelven a introducir en el Product Backlog. El trabajo finalizado en ellos pierde valor con rapidez y frecuentemente debe volverse a estimar.

Las cancelaciones de Sprint consumen recursos, ya que todos deben reagruparse en otra Reunión de Planificación de Sprint para empezar otro Sprint. Las cancelaciones de Sprint son a menudo traumáticas para el Equipo Scrum y son muy poco comunes.

Existen varias prácticas para pronosticar el progreso, como gráficos de burn-downs, burn-ups, o flujos acumulativos.

El burndown chart es una gráfica sencilla de leer, que revela los datos de la velocidad con la que se está desarrollando un Sprint.

Eventos Scrum

    • Los Sprints
    • Sprint Planning (Planificación del Sprint)
    • Daily Scrum (Scrum Diario)
    • Sprint Review (Revisión del Sprint)
    • Sprint Retrospective (Retrospectiva del Sprint)
  • Cada evento en Scrum es una oportunidad formal para inspeccionar y adaptar los artefactos de Scrum.
  • Estos eventos están diseñados específicamente para habilitar (permitir) la transparencia requerida (necesaria).
  • Si no se realizan los eventos según lo prescrito, se pierden oportunidades para inspeccionar y adaptarse.
  • Los eventos se utilizan en Scrum para crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum.
  • Lo óptimo es que todos los eventos se celebren al mismo tiempo y en el mismo lugar para reducir la complejidad.