Revisión del Sprint

Smartpedia: La Revisión del Sprint es una reunión de desarrolladores, Scrum Master y Product Owner al final de un Sprint para presentar los resultados del desarrollo y determinar los ajustes futuros.

La revisión del sprint es una reunión al final de un sprint para evaluar el trabajo realizado en relación con el objetivo del sprint. La Guía Scrum define: “El propósito del Sprint Review es inspeccionar el resultado del Sprint y determinar adaptaciones futuras. El equipo Scrum presenta los resultados de su trabajo a las partes interesadas clave y se discute el progreso hacia el objetivo del producto. Durante el evento, el equipo Scrum y las partes interesadas revisan lo que se logró en el Sprint y lo que ha cambiado en su entorno. A partir de esta información, los asistentes colaboran sobre qué hacer a continuación”.
Idealmente, el equipo ha completado cada elemento de la lista de trabajos pendientes del sprint, pero lo que es más importante, han logrado el objetivo del sprint acordado en la planificación del sprint. Durante la revisión solo se presentan los elementos que realmente se completaron de acuerdo con la Definición de Terminado.

La revisión del sprint cuenta con la asistencia de todo el equipo Scrum (los desarrolladores, el Scrum Master y el Product Owner) e idealmente también las partes interesadas, como usuarios, gerentes, representantes de áreas como marketing, ventas y TI. Por supuesto, la revisión del sprint no se dirige a todas las partes interesadas; los competidores también se ven afectados por los resultados, pero no querrán contribuir a mejorar el producto de un competidor. En la práctica, el enfoque de la reunión está principalmente en el intercambio entre los desarrolladores y el Product Owner como representante de las partes interesadas. Si el Product Owner no puede cubrir todos los aspectos técnicos, el cliente debe participar en la revisión del sprint o enviar un sustituto apropiado. Si esto no es posible, se pospondrá la aceptación de las historias de usuario correspondientes. En el caso de historias complejas, el cliente ya debería estar involucrado antes de la revisión real, de lo contrario, la aceptación podría volverse demasiado extensa y fallar.

Scrum define diferentes eventos, que se ejecutan una o varias veces. Estos incluyen la Planificación del Sprint, el Scrum Diario y la Retrospectiva. El Refinamiento del Backlog también se lleva a cabo como una tarea continua; por lo tanto, no es explícitamente un evento Scrum.

Solo el número de eventos, a veces denominados rituales, ceremonias o reuniones, revela la importancia de la comunicación en un contexto ágil. Ningún evento es más importante que otro, porque cada uno persigue sus propios objetivos y un significado concreto. El propósito de la Revisión del Sprint es la retroalimentación de las partes interesadas (opiniones, críticas, elogios y sugerencias de mejora) que fluyen hacia el desarrollo posterior.

Después de un breve saludo – un descongelamiento es innecesario en sí mismo y va en contra del tiempo acordado – por parte del Product Owner y una breve presentación de los participantes, si no se conocen, sigue la explicación de las reglas. Una regla de oro como la de la Retrospectiva del Sprint es especialmente útil. Antes de que el equipo comience a presentar las historias de usuario completadas, el Product Owner debe presentar y, si es necesario, distribuir una lista que muestre qué elementos se han implementado y demostrado y cuáles no. Esta lista debe acordarse de antemano entre el Product Owner y el equipo de desarrollo, ya que también determina la secuencia de presentación posterior de los elementos implementados. En algunas organizaciones, esta lista que se envía con la invitación a la Revisión del Sprint, porque esto facilita que los visitantes de marketing o ventas decidan si tiene sentido para ellos participar.

El corazón de la Revisión del Sprint es la presentación de la nueva funcionalidad, idealmente por los propios desarrolladores. Aquí es donde se solicita la retroalimentación de los participantes y, en el mejor de los casos, se aceptan las historias de usuario, pero si es necesario, no se aceptan. Antes de que se lleve a cabo una discusión sobre los próximos elementos del backlog, el Scrum Master puede explicar los mayores desafíos del sprint. En la mayoría de los casos, estos puntos de relacionan más con el proceso que con la implementación de los requisitos. La Revisión del Sprint debería terminar con un agradecimiento a los desarrolladores y presentadores y la fecha para la próxima Revisión del Sprint.

La comunicación y la retroalimentación son muy importantes en Scrum. Para que esta comunicación se desarrolle de forma ordenada y no suponga demasiado esfuerzo en las distintas reuniones, es recomendable utilizar un timebox (tiempo fijo). La Guía Scrum recomienda un espacio de tiempo de 4 horas o menos para una revisión de los sprints de un mes, 3 horas o menos para un sprint de tres semanas, etc.

Para mantener el horario acordado, es necesario comunicarse de manera significativa y estructurada. Tiene mucho sentido describir el proceso a todos los participantes al comienzo de la revisión, incluso si la mayoría o incluso todos los participantes han participado antes en Revisiones del Sprint. La explicación del objetivo del sprint, la consideración del progreso hacia el objetivo del producto y el nombramiento de la caja de tiempo proporcionan a los participantes puntos de orientación adicionales.

Si el cliente participa en la reunión, puede haber discusiones extensas sobre la intención de los requisitos y el diseño de nuevas funciones. Aquí también es importante estar atento al tiempo fijo. Posiblemente, las reuniones separadas con un número menor de participantes tienen más sentido y reducen el esfuerzo.

Realizar una revisión del sprint al final de un sprint tiene varias ventajas:

• La revisión del sprint revela lo que ya se ha trabajado. Dado que solo las historias de usuario realizadas y su implementación se pueden presentar en vivo en el producto, el progreso del desarrollo es directamente visible para todos los participantes.
• Existe una retroalimentación directa entre los desarrolladores y las partes interesadas y, por lo tanto, críticas, elogios o sugerencias de mejora. El Product Owner puede planificarlos para el próximo sprint.
• Las partes interesadas reciben información animada sobre el desarrollo en lugar de informes anónimos. Esto hace que sea mucho más fácil lidiar con los resultados.
• El esfuerzo de preparación para los desarrolladores es bajo, porque solo se presentan las soluciones terminadas. Las presentaciones de PowerPoint o medios similares deben evitarse en las revisiones.
• Aumenta la identificación del equipo con los resultados de su propio trabajo.
• Se pueden desarrollar juntos ideas para otras funcionalidades.

Hay una serie de consejos y trucos que pueden contribuir al éxito de una revisión del sprint:

• El número de participantes puede llegar a ser muy grande, por lo que es muy importante una buena moderación, reglas y procedimientos claros, así como una alineación constante con el plazo acordado.
• Por lo general, el Product Owner también es el moderador del evento Scrum. Así que tiene dos sombreros puestos, que tiene que separar en cualquier caso. Por supuesto, puede dar comentarios, pero debe ser reservado, por ejemplo, al planificar nuevas historias de usuarios directamente debido a los comentarios proporcionados.
• La participación de las partes interesadas importantes es esencial, porque sus comentarios verificar claramente el valor real de la implementación.
• Las bajas habilidades de presentación de los desarrolladores pueden provocar una falta de aceptación entre las partes interesadas. Aquí se debe tomar una decisión consciente si una regla interna (la característica la presenta el desarrollador que la implementó) debe conservarse o, en un caso particular, manejarse alternativamente.
• La publicación de historias de usuarios implementadas es importante, pero la retroalimentación es mucho más importante. La retroalimentación de como resultado las aprobaciones. Si la Revisión del Sprint se convierte en un evento de lanzamiento puro, se pierde el significado real.

Hay buenas razones por las que las características de un software se presentan en tiempo real antes de que el software esté completamente desarrollado. Incluso si hay gerentes que no quieren invertir mucho tiempo en tales presentaciones, a largo plazo es la única forma de observar el progreso de un desarrollo. Los mensajes de progreso enviados por correo electrónico o información entre puertas pueden funcionar, pero es mucho más probable que al final se produzcan resultados sorprendentes para uno u otro responsable. La presentación regular de los resultados brinda a la gerencia y a otras partes interesadas importantes la oportunidad de obtener sus propias impresiones, identificar desarrollos indeseables, dar retroalimentación o expresar deseos e ideas.