Subdirección de las Tecnologías de la Información y Comunicaciones

Área de Gobernanza y Calidad

Contenido

Resumen

Versión: v01r02
Fecha publicación: 30 de Julio de 2021
Entrada en vigor desde: 30 de Julio de 2021

Histórico de cambios

Los cambios en los estándares vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución.

Versión	v01r01	Fecha publicación	29 de Octubre de 2020	Fecha entrada en vigor	29 de Octubre de 2020
Alcance
Sprint Review; Objetivo, contenido, agenda típica, responsabilidades, preparación de la sesión y buenas prácticas
Versión	v01r02	Fecha publicación	30 de Julio de 2021	Fecha entrada en vigor	30 de Julio de 2021
Alcance
Se alinea la nomenclatura utilizada con la Scrum Guide del 20 de Noviembre de 2020; sustituyéndose el término "rol" por el de "responsabilidades" y el de "equipo de desarrollo" por "desarrolladores" Se refuerza el mensaje de completar el trabajo durante el Sprint y que la Review no sea la puerta para liberar valor, de acuerdo a la guía SCRUM del 20 de Noviembre de 2020 Se refuerza el mensaje de que la Review sea una sesión colaborativa en lugar en una presentación unidireccional, de acuerdo a la guía SCRUM del 20 de Noviembre de 2020

Introducción

Esta página pretende esclarecer los aspectos fundamentales de las sesiones Sprint Review.

Objetivo

Alineamiento: Los desarrolladores se comprometieron con unos objetivos para el sprint y durante la Sprint Review es el momento en el que alinean con el resto de interesados qué trabajo se ha completado durante el Sprint y cuál no, pidiendo a los Product Owners (o equivalentes) aceptación formal para el trabajo completado.
Demostración Práctica (Show & Tell): Visualizar el progreso asociado al incremento a través de Software que funciona.
Conseguir feedback directo: Escuchar de Product Owners o usuarios feedback del producto desarrollado (¿Cómo de útiles es el producto?, ¿sirven el propósito inicial?, ¿qué otras ideas podrían desprenderse de este producto?).
Ofrecer una visibilidad del desarrollo del sprint: El equipo ofrece a los interesados una ventana de visibilidad acerca de cómo el equipo ha trabajado tanto conjuntamente como en el contexto de la organización (p.ej. con otras áreas de la STIC). La Sprint Review es un buen momento para dar visibilidad de los impedimentos recurrentes.
Revisión de deuda Técnica.
Obtención del grado de satisfacción de los desarrolladores y Product Owner con el Sprint.

Contenido y Agenda típica

Revisar el grado de consecución de objetivos del SPRINT y de sus historias de usuario a través de Software que funciona.
Comprobar las validaciones funcionales y del DoD realizadas durante el Sprint.
Obtener feedback de Product Owners sobre el incremento del Producto.

Responsabilidades

Responsabilidad Scrum	Descripción
Proxy Product Owner	Gestión de la convocatoria así como de la agenda, siendo imprescindible evaluar, comunicar y coordinar de manera proactiva y de antemano posibles disrupciones que comprometan la sesión: falta de asistencia de invitados clave, urgencias,… * Asegurar que se ha llevado a cabo la coordinación previa con Sistemas, OTI, Calidad,…en caso de necesitar requerimientos de áreas específicas. Garantizar que los resultados son conformes con los requisitos, garantizando así el éxito y aceptación del proyecto. Asegurar la comunicación y seguimiento de cualquier información o acción relevante que se desprenda de la sesión con los/as interesados/as del proyecto relevantes si estos/as no están presentes en la Sprint Review. Garantizar la recepción y comprobación de entregables.
Scrum Master	Gestión de la convocatoria así como de la agenda, siendo imprescindible evaluar, comunicar y coordinar de manera proactiva y de antemano posibles disrupciones que comprometan la sesión: falta de asistencia de invitados clave, urgencias,… * Facilitación de la sesión (mantener tiempos, mantener el foco de la sesión, asegurar que las acciones y decisiones quedan grabadas, incentivar la participación de todo el mundo, etc). Ayudar a desarrolladores en la preparación de la sesión. Asegurar toma de métricas tras la sesión. Asegurar disponibilidad del resumen de la sesión en Confluence.
Desarrolladores	Comunicar estado de las HUs del Sprint. Demo del sistema.
Stakeholder OCA	La responsabilidad de la OCA en la Sprint Review deberá pactarse para cada proyecto, siendo necesario alinear si aplican o no las siguientes responsabilidades: Antes de la Sprint Review, el representante de la OCA en el proyecto realizará, a nivel de historia de usuario de acuerdo a la normativa vigente, lo siguiente: Verificación de estructura Repositorio GIT. Verificación de uso correcto de Gitflow. Verificación de diversas cuestiones relacionadas con la estructura de la carpeta del proyecto y algunos de sus ficheros: campos fichero Readme.md, estructura de los archivos pom.xml, documentos .feature, cumplimiento normativa Oracle. Validación no funcional de las Historias de Usuario. Validación de la compilación en Jenkins. Validación del análisis estático del código cumpliendo normativa o acuerdo DoD. Verificación de cumplimiento normativa Oracle. Comprobación de que las pruebas de regresión se han ejecutado correctamente (sólo si procede). Durante la Sprint Review, el representante de la OCA en el proyecto comprobará que las historias de usuario cumplen el DoD. Pruebas funcionales a Sprint pasado con el objetivo de lograr una detección temprana de errores.
Product Owner	Asistir a la Sprint Review para validar el Producto desarrollado durante el SPRINT.

(*) En cada proyecto es importante que Scrum Master y Proxy Product Owner alineen conjuntamente quién gestionará la convocatoria. La persona finalmente encargada de gestionar la convocatoria deberá prestar especial atención a comunicar y gestionar proactivamente posibles disrupciones que comprometan la sesión (p.ej. falta de asistencia de invitados clave, urgencias, etc).

Preparación de la sesión

Input	Descripción	Responsable preparación de la sesión	Fuente de información
Revisión de la agenda	Revisar la agenda de manera que se obtengan los resultados esperados de la sesión: Validación del contenido del Sprint (cumplimiento DoD). Listado de acciones y pendientes. Valoración del sprint por Product Owners y desarrolladores	Scrum Master ó Proxy Product Owner **	Scrum Master ó Proxy Product Owner **
Envío de convocatoria	Envío con suficiente antelación de la convocatoria, asegurando la relevancia de la lista de invitados a la sesión.	Scrum Master ó Proxy Product Owner **	Scrum Master ó Proxy Product Owner **
Gestión de la convocatoria	En caso de avisos de no asistencia o indisponibilidad, se deberá gestionar de manera proactiva la convocatoria para asegurar que se mantiene la eficiencia de la misma (p.ej. buscando fecha alternativa, asegurando que las responsabilidades son correctamente delegadas, etc).	Scrum Master ó Proxy Product Owner **	Interesados relevantes del Sprint
Alineamiento de validaciones de previas (si aplica)	En caso de requerirse de la validación de requisitos impuestos por interesados externos al equipo del proyecto, se asegurará o bien la asistencia de dichos interesados a la review o bien se deberá velar por la validación de dichos requisitos con anterioridad a la review.	Scrum Master ó Proxy Product Owner **	Otros interesados
Estado del DoD	Asegurar feedback previo relacionado con: La disponibilidad del plan de pruebas del sprint. El estado de la subida del código a GIT siguiendo la normativa Gitflow, así como de la subida de los archivos .features a GIT. El estado de la compilación Jenkins del incremento. El estado del análisis estático del código. El despliegue de incremento en el entorno acordado. La actualización del Backlog de acuerdo al contenido desarrollado, así como de la documentación del proyecto relacionada con el sprint. El resultado de las pruebas automáticas del sprint.	Scrum Master	Desarrolladores
Preparación de revisión de Historias de Usuario y criterios no funcionales	Asegurar que los desarrolladores tienen conocimiento previo de cómo se va a ejecutar la Demo de las Historias de Usuario del Sprint, de cuáles son los Criterios de Aceptación que se validarán durante la Review y de cómo de cómo se va a demostrar el cumplimiento con dichos Criterios de Aceptación así como con los requisitos no funcionales del proyecto. NOTA: se recomienda organizar una sesión previa días antes de la review junto con el equipo para tratar este punto así como los siguientes relacionados con el DoD.	Scrum Master	Desarrolladores

(**) Scrum Master ó Proxy Product Owner según se convenga para cada proyecto.

Buenas Prácticas

Limitar el tiempo de preparación de la Demo (1 o 2 horas).
La preparación de la Demo comienza en el Sprint Planning.
Asegurar que los participantes adecuados están presentes.
Asegurar que el equipo celebra los logros y éxitos y que los “stakeholders” así lo reconocen.
Asegurar que diferentes miembros del equipo participan en la Demo.
Asegurar que el equipo está preparado para la Demo, y si aplica, están coordinados con el equipo de Sistemas para la revisión de una Versión.
Asegurar que todas las HUs están validadas funcionalmente con los PPOs y cerradas antes de la sesión.

Anti-patrones

Se emplea mucho tiempo en la preparación de la Demo.
La Demo se desarrolla a modo de discurso/diapositivas en lugar de apoyarse sobre software/hardware en funcionamiento.
El Product Owner ve una funcionalidad en la Demo de la que no tenía constancia.
Pensar que las Demos no son relevantes para “stakeholders” a nivel dirección / programas.
Utilizar la Review para realizar la validación funcional y cerrar todas las HUs en lugar de cerrarlas durante el Sprint.

Árbol de páginas

Sprint Review