7.4 - Etapa 4: Revisión del Sprint

El objetivo de esta etapa es recolectar retroalimentación de cada uno de los Sprints, y así, permitir la adaptación y mejora continua tanto del producto como de las prácticas ejecutadas por el Equipo Scrum. Está compuesta por 2 prácticas que son iterativas y deberán ejecutarse en cada Sprint.

Durante esta etapa del ciclo de vida, también se realiza el monitoreo y control del proyecto, dando paso a: Gestión de Cambios, Gestión de Riesgos y la Gestión Financiera.

dibujo

ID	Práctica	Rol vs Nivel de Involucramiento
	Etapa 4: Revisión del Sprint
12	7.4.1 - Reunión de Revisión del Sprint (12)	Product Owner: Alto - Scrum Master: Alto - Equipo de desarrollo: Alto
13	7.4.2 - Reunión de Retrospectiva del Sprint (13)	Product Owner: Nulo - Scrum Master: Alto - Equipo de desarrollo: Alto

7.4.1 - Reunión de Revisión del Sprint (12)

En esta reunión de revisión se realiza la demostración del incremento de producto al Product Owner y partes interesadas invitadas, con el fin de obtener aprobación sobre lo que se esperaba y lo que fue desarrollado por el equipo.

A continuación, se listan las actividades que se realizan durante la Reunión de Revisión del Sprint:

• Presentar el incremento de producto: El equipo de desarrollo presenta al Product Owner y al Scrum Master el incremento del producto desarrollado.
• Probar el incremento de producto (Validación): El Product Owner y las partes interesadas invitadas (solo si las hay) prueban el incremento de producto con base en la comparación del desarrollo frente a cada historia de usuario y sus criterios de aceptación. (Es válido que se cuente con una lista de chequeo para llevar el registro de lo que se cumple y lo que no se cumple).
• Aprobación del incremento de producto: Con base en el incremento presentado y la validación el Product Owner da la aprobación del incremento de producto. En caso que el incremento no cumpla con lo esperado puede darse el Rechazo del incremento.
• Monitoreo, control y seguimiento del proyecto: Ver más en Sección 6.2 Seguimiento y control del proyecto.
• Ritmo/velocidad del equipo: Se identifica el ritmo/velocidad del Equipo de Desarrollo.
• Compromisos del equipo: Se identifican compromisos por parte del equipo en caso del rechazo del incremento de producto o de historias de usuario puntuales.
  • En caso de rechazo se agregan las mejoras al Product Backlog con la prioridad más alta posible, con el fin de corregirlas en el próximo sprint de ser posible.
• Actualizar el Product Backlog: Se debe actualizar el Product Backlog y dar por terminado el sprint actual.

¿Cómo se realizan las validaciones? En esta reunión se presenta el incremento de producto ante los interesados, los cuales se cerciorarán que cada una de las funcionalidades establecidas y solicitadas en el Sprint estén terminadas (bajo los lineamientos de los criterios de aceptación y los criterios de “terminado”).

7.4.1.1 - Deuda técnica

La deuda técnica se refiere al trabajo que los equipos omiten o no se completa durante uno o varios Sprints.

• Si la deuda técnica se acumula, puede conllevar a un mantenimiento, integración y costos elevados en el despliegue del producto.
• La priorización frecuente de Historias de Usuario contribuye a disminuir la deuda técnica.
• Cualquier deuda técnica no debería llevarse más allá de un sprint.

Algunas de las causas de la deuda técnica son:

• Evaluación inadecuada o incompleta de Historias de Usuario
• Falta de coordinación entre los miembros del equipo
• Intercambio deficiente del conocimiento empresarial

7.4.1.2 - Refinamiento del Product Backlog

El refinamiento del Product Backlog es el acto de añadir detalle, estimaciones y orden a los elementos del Product Backlog; se trata de una actividad continua en la cual el Product Owner y el Equipo de Desarrollo examinan, revisan y detallan los elementos del Product Backlog.

• Los elementos del Product Backlog pueden actualizarse en cualquier momento por El Product Owner o a criterio suyo.
• El refinamiento usualmente consume no más del 10% del tiempo de la Reunión de Revisión del Sprint.

7.4.2 - Reunión de Retrospectiva del Sprint (13)

La Retrospectiva del Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint. La Retrospectiva debería realizarse en un ambiente liberador que permita al equipo fluir todo tipo de ideas.

La Retrospectiva del Sprint tiene lugar después de la Revisión de Sprint (Sprint Review) y antes de la siguiente Planificación de Sprint. Se trata de una reunión restringida a lo máximo de 4 horas para Sprints de un mes.

El Scrum Master enseña a todos a mantener el evento positivo y productivo; y participa de esta reunión como un miembro del equipo ya que parte de la responsabilidad de los incrementos recae sobre él.

El Scrum Master motiva al equipo para que mejore su proceso de desarrollo y sus prácticas para hacerlos más efectivos y amenos para el siguiente Sprint. Durante cada Retrospectiva del Sprint el Equipo Scrum identifica y planifica formas de mejorar la calidad del producto mediante el mejoramiento de la calidad de las prácticas, que pueden ser implementadas en el próximo Sprint.

El hecho de implementar estas mejoras en el siguiente Sprint constituye la adaptación subsecuente a la inspección del Equipo de Desarrollo mismo. Aunque las mejoras pueden implementarse en cualquier momento, la Retrospectiva del Sprint ofrece un evento dedicado para este fin, enfocado en la inspección y la adaptación.

En resumen, durante la Retrospectiva:

• El equipo de trabajo se enfoca en responder a las siguientes preguntas:
  • Qué cosas han funcionado bien.
  • Cuáles hay que mejorar.
  • Qué cosas quiere probar el equipo en la siguiente iteración.
  • Qué ha aprendido el equipo.
• El equipo identifica las mejoras accionables para mantener o mejorar el trabajo del equipo, y mantener la motivación de los miembros.
• El equipo documenta y actualiza el registro de lecciones aprendidas.

7.4.2.1 - Técnicas para la realización de la Retrospectiva del Sprint

La retrospectiva es una de las ceremonias más importantes dentro del desarrollo de un proyecto usando Scrum, ya que es una de las principales fuentes de aprendizaje continuo que tiene el equipo, además sirve para mantener la motivación y el compromiso con el proceso de desarrollo.

Uno de los elementos que se deben tener en cuenta, es que el realizarla siempre de la misma manera (monotonía), podría disminuir el interés de los equipos en participar. Así que muchos de los Scrum Máster, suelen utilizar la reunión de retrospectiva del Sprint como un evento en el cual experimentar e introducir nuevas técnicas.

Por lo general una retrospectiva suele tener 5 momentos importantes:

1. Preparación de la sesión
2. Recolección/Análisis de los datos
3. Generar ideas de mejora/cambio
4. Definir los planes de acción (experimentos a aplicar en los próximos Sprint)
5. Recolección de retroalimentación de la retrospectiva

A continuación, se mencionan algunas de las tantas técnicas disponibles que se pueden realizar como parte de una Retrospectiva del Sprint.

Índice de felicidad del Equipo El índice de felicidad del equipo es una técnica utilizada para medir el nivel de felicidad alrededor del tiempo de cada uno de los miembros de un equipo. Se caracteriza por su facilidad de aplicación, además de tener el anonimato como uno de sus pilares centrales.

Para aplicar la técnica, el Scrum Master suele construir un tablero (canvas) como el que se muestra a continuación:

dibujo

• Suele estar en un lugar visible de las oficinas de trabajo del equipo Scrum
• Si está físico (recomendable), se utilizan stickers de colores para completar el tablero y así mapear el estado de ánimo
• Las variaciones en la felicidad del equipo, pueden ser el reflejo de las situaciones vividas en la organización.
• Es una medición subjetiva, por lo que los resultados deben manejarse con precaución
• Le aportan bastante valor a las labores realizadas por el Scrum Master, ya que se puede enfocar en hacer la vida más feliz a todos los miembros de los equipos que lidera.
• Siempre se debe garantizar el anonimato, ya que, de lo contrario, los resultados mostrados en el tablero no serán precisos o acordes a la realidad
• Aunque los datos se recolectan a lo largo del desarrollo de un Sprint, su análisis se puede hacer en conjunto con todo el equipo como parte de una retrospectiva.

4L’s

Esta técnica descrita ampliamente en el libro “Agile Retrospectives” se utiliza como ejercicio en las retrospectivas. Consiste en un tablero (canvas) dividido en 4 cuadrantes:

1. Liked: Aquí cada uno de los miembros puede poner todas las cosas que les gustaron durante el desarrollo del Sprint (Ej: La planificación organizada, la nueva herramienta con la que se trabajó, una nueva técnica implementada por el Scrum Master, etc)
2. Learned: En esta sección, se listan todos aquellos elementos que el equipo siente que aprendió y que le servirán para próximos Sprints (Ej: La importancia de comentar el código, nuevas técnicas para revisar los entregables, nuevas técnicas de retrospectiva, etc)
3. Lacked: Aquí se colocan todas las cosas que faltaron durante el Sprint, así como las necesidades que el equipo tiene. (Por lo general suelen estar asociadas a impedimentos que haya tenido el equipo)
4. Longed For: Acá los integrantes del equipo colocan todas aquellas cosas que quieren que sucedan en el futuro próximo (Ej: Mayor participación del cliente, mejor redacción en las historias de usuario, una nueva herramienta, etc)

dibujo

• Suele tenerse el canvas impreso y disponible en la oficina, para ser completado con sticky-notes
• Todos los datos son analizados por el Scrum Master, en conjunto con los miembros del equipo para así definir planes de acción para los próximos Sprint.

Feedback

Con el fin de que los equipos de trabajo tengan oportunidades de mejora en sus enfoques y desarrollo del trabajo, es necesario que el líder del equipo o incluso entre colegas, una vez finalizado un Sprint (o en cualquier momento que se considere necesario), se brinden retroalimentación.

El objetivo de la retroalimentación es hablar de situaciones buenas, para alentar dichos comportamientos, o de situaciones malas, para que la otra persona pueda convertirlas en oportunidades de cambio. Las sesiones de retroalimentación están orientadas a mejorar y fortalecer al equipo de trabajo, ayudando al desarrollo de competencias y crecimiento personal, individual y grupal.

Las sesiones de retroalimentación suelen tener las siguientes características:

1. Son reuniones en privado por lo general
2. No solo deberían usarse para hablar de cosas negativas
3. No sólo deberían realizarse por los líderes, también debería alentarse la realización de retroalimentación entre compañeros de equipo, así que por lo general la retroalimentación hace parte de una cultura de mejora y aprendizaje continuo.
4. La retroalimentación debe realizarse de forma continua
5. Siempre debería realizarse de forma inmediata al hecho o hechos que se vayan a tratar durante la sesión.

Feedforward El feedforward es una variación de la retroalimentación, esta técnica se centra más en las posibilidades futuras que en errores pasados, no solo se trata de comunicar, sino de hacerlo pensando en las oportunidades de mejoramiento de las prácticas a futuro, todo bajo un ambiente de motivación, optimismo y pensando en todo aquello que se pueda lograr para trasformar las oportunidades en casos de éxito.

Son características que se deben tener en cuenta:

• Dar sugerencias para el futuro y aprender tanto como se pueda. • No se deberían tratar hechos pasados. • Es más productivo que el feedback, puesto que ayuda a las personas a hacer lo “correcto” más que probar que estaban “equivocados”.