Reglas de las ceremonias de Scrum: reunión de revisión del Sprint

La reunión de revisión de Sprint tiene un límite de tiempo de 4 horas.

  • El equipo no debe pasar más de 1 hora preparándose para la revisión del Sprint.
  • El propósito de la revisión de Sprint es que el equipo presente al propietario del producto y a las partes interesadas la funcionalidad que se ha realizado. Aunque el significado de «hecho» puede variar de una organización a otra, generalmente significa que la funcionalidad está completamente diseñada y podría enviarse o implementarse potencialmente. Si «hecho» tiene otro
    significado, asegúrese de que el propietario del producto y las partes interesadas lo entiendan.
  • La funcionalidad que no está «hecha» no se puede presentar.
  • Los artefactos que no son funcionalidades no se pueden presentar, excepto cuando se usan para ayudar a comprender la funcionalidad demostrada.
    Los artefactos no pueden mostrarse como productos de trabajo y su uso debe minimizarse para evitar confundir a las partes interesadas o exigirles que entiendan cómo funciona el desarrollo de sistemas.
  • La funcionalidad debe presentarse en las estaciones de trabajo de los miembros del equipo y ejecutarse desde el servidor más cercano a la producción, generalmente un servidor de entorno de control de calidad (QA).
  • La revisión del Sprint comienza cuando un miembro del equipo presenta el objetivo del Sprint, el Product Backlog comprometido y el Product Backlog completado. Luego, diferentes miembros del equipo pueden discutir qué salió bien y qué no salió bien en el Sprint.
  • La mayor parte de la revisión del Sprint se dedica a que los miembros del equipo presenten la funcionalidad, respondan las preguntas de las partes interesadas con respecto a la presentación y anoten los cambios que se desean.
  • Al final de las presentaciones, se encuesta a las partes interesadas, una por una, para obtener sus impresiones, los cambios deseados y la prioridad de estos cambios.
  • El propietario del producto analiza con las partes interesadas y el equipo la posible reorganización de la cartera de productos en función de los comentarios.
  • Las partes interesadas son libres de expresar cualquier comentario, observación o crítica con respecto al incremento de la funcionalidad del producto potencialmente entregable entre presentaciones.
  • Las partes interesadas pueden identificar la funcionalidad que no se entregó o no se entregó como se esperaba y solicitar que dicha funcionalidad se coloque en la Lista de Producto para su priorización.
  • Las partes interesadas pueden identificar cualquier funcionalidad nueva que se les ocurra mientras ven la presentación y solicitar que la funcionalidad se agregue a la Lista de Producto para su priorización.

Artículos de eventos de Scrum

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.