Las reglas de Scrum (III): El Sprint Review Meeting

Aquí teneís la tercera entrega de la traducción sobre las reglas de Scrum. Antes de leer este post deberiaís leer el primero, sobre la reglas del Sprint Planning Meeting y el segundo, sobre las reglas durante el Sprint.


El Sprint review meeting proporciona un punto de inspección para el progreso del proyecto al final de cada Sprint. Basándose en esta inspección, se pueden hacer adaptaciones al proyecto. El Equipo estimó donde estaría al final del Sprint y estableció su camino hacia ese punto. Al final del Sprint el equipo presenta el incremento del producto que ha sido capaz de implementar. Los gestores, clientes, usuarios y el Product Owner determina el incremento del producto, escuchan las historias que el equipo tiene que contar sobre su camino durante el Sprint, Oyen que ha ido bien y que ha ido mal. Después de esto, estarán capacitados para tomar una decisión basada en información sobre que hacer después. En otras palabras, determinarán el mejor camino a tomar para alcanzar las metas perseguidas.


  • El Sprint review meeting está limitado a 4 horas.

  • El propósito del Sprint review es que el Equipo presente al Product Owner y los stakeholders la funcionalidad que está completada. Aunque el significado de «completado» puede variar de una organización a otra, habitualmente significa que la funcionalidad esta completamente desarrollada y, potencialmente, podría ser entregada o implementada. Si «completado» tiene otro significado debemos estar seguros que el Product Owner y los stakeholders lo entienden.

  • La funcionalidad que no esta «completada» no puede ser presentada.

  • Artefactos que no son funcionalidad no pueden ser presentados excepto cuando se usan para mejorar el entendimiento de la funcionalidad demostrada. Los artefactos no pueden ser mostrados como productos de trabajo, y su uso debe ser minimizado para evitar confundir a los stakeholders o exigir que estos entiendan como funciona el desarrollo del sistema.

  • La funcionalidad deberá ser presentada en los equipos de trabajo de los miembros del Equipo y ejecutada desde un servidor lo más parecido posible a uno de producción, usualmente un servidor del entorno de aseguramiento de la calidad.

  • El Sprint review comienza con un miembro del Equipo presentando las metas del Sprint, el Product Backlog comprometido y el Product Backlog completado. Diferentes miembros del equipo pueden comentar que fue bien y que no fue bien en el Sprint.

  • La mayoría del Sprint review se consume con los miembros del Equipo presentando funcionalidad, respondiendo preguntas de los stakeholders sobre la presentación y descubriendo que cambios desean estos.

  • Al final de la presentación, los stakeholders son encuestados, uno a uno, para recoger sus impresiones, que cambios desean, y la prioridad de esos cambios.

  • El Product Owner discute con los stakeholders y el Equipo el potencial cambio del Product Backlog basándose en su feedback.

  • Los stakeholders son libres de realizar en voz alta cualquier comentario, observación o crítica sobre el incremento de funcionalidad potencialmente entregable entre presentaciones.

  • Los stakeholders pueden identificar funcionalidad que no ha sido entregada o no ha sido entregada según sus expectativas y solicitar que dicha funcionalidad sea incluida en el Product Backlog para su priorización.

  • Los stakeholders pueden identificar cualquier funcionalidad que se les ocurra mientras ven la presentación y solicitar que dicha funcionalidad sea añadida al Product Backlog para su priorización.

  • El ScrumMaster debe intentar determinar el número de personas que se espera asistan al Sprint review meeting y montar la reunión para acomodarles.

  • Al final del Sprint review, el ScrumMaster anuncia al Product Owner y los stakeholders el lugar y la fecha donde tendrá lugar el próximo Sprint review meeting.

3 comentarios sobre “Las reglas de Scrum (III): El Sprint Review Meeting”

  1. Hola Rodrigo, estuve el martes en el seminario que hicisteis en Madrid sobre Team System y Scrum, y la verdad que estuvo muy bien, enhorabuena.

    Me surge una duda después de leer este artículo. Dices que la fecha del siguiente sprint review meeting se fija durante el sprint review meeting, pero ¿no sería más apropiado fijarla durante el sprint planning meeting? De esta forma tendrías más libertad a la hora de planear el sprint.

    Un saludo,

    Manuel.

  2. Hola Manuel:

    Gracias, me alegro de que te gustase nuestra presentación.

    Es importante anunciar la fecha del siguiente Sprint Review en el Sprint Review actual para que la gente pueda hacer un hueco en su agenda con la antelación suficiente.

    De todos modos es cierto que muchos equipos esperan al Sprint Planning Meeting para elegir la fecha y luego la anuncian por email o en el portal de proyecto. Esto tiene la ventaja de que además de la fecha se puede anunciar que es lo que el equipo va a abordar durante el sprint.

    Un saludo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *