Revisión Sprint (Sprint Review)

Progreso del Lección
0% Completado

Revisión Sprint (Sprint Review)

  • La reunión Revisión del Sprint, (“Sprint Review”), es una reunión de mejorar continua, inspección, adaptación de producto.
  • Es la reunión donde se entrega el incremento de valor del Sprint al Propietario de Producto (“Product Owner”).
  • El Equipos de Desarrollo, le realiza una sesión de “Demo, Demostración” de lo entregado.
  • Es la reunión donde se verifican que se ha alcanzado el objetivo del Sprint, la DoD (Definición de Hecho), y todos los Criterios de Aceptación.
  • Participar todo el Equipo Scrum (“Scrum Team”), el Scrum Master, suele ser la persona que facilita y realiza la Demo la Propietario de Producto (“Product Owner”).

  • Su duración, como la mayoría de eventos, depende de la duración del Sprint.
  • Sprint 4 semanas – Duración máxima 4 horas.
  • Sprint 3 semanas – Duración máxima 3 horas.
  • Sprint 2 semanas – Duración máxima 2 horas.
  • Sprint 1 semana – Duración máxima 1 horas.


  • Lo común, es que dentro del Equipo de Desarrollo, exista un miembro que es la QA, “Calidad”, y que se va asegurando que la calidad, el objetivo, los criterios de aceptación, definición de hecho, se vayan cumpliendo para que cuando realicemos la Demo al Propietario de Producto (“Product Owner”) en la Revisión del Sprint sea todo un éxito. La persona de QA, muchas veces va enseñando de forma “informal”, lo que el va verificando, para que la Demo sea más fácil, y que las probabilidades de éxito esté asegurado.
  • Si el Propietario del Producto (“Product Owner”), no aceptará algo en la Revisión del Sprint (“Sprint Review”), entonces se suele reunir el Equipo Scrum, para analizar la situación, la no aceptación que impacto tiene, si lo pueden resolver ese mismo día, o si no es el caso, se analiza, se estima, y el Propietario de Producto, lo incorpora a la Pila de Producto (“Product Backlog”), se reprioriza. Lo común es que se incluya para el siguiente Sprint, con lo comprometido, o se mueva, algo del siguiente Sprint, al siguiente, para poder incorporar la no aceptación.
  • Debido a esto, es necesario, que la Pila del Producto, (“Product Backlog”), en su totalidad o por Sprints, exista una reserva de contingencia, para poder gestionar, cambios, no aceptaciones, errores, etc.. . Se suele reservar entre un 5%-10% por Sprint o para todo la Pila de Producto (“Product Backlog”).