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:

¿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.

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

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.

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:

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

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

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”.


Revision #1
Created 18 January 2021 17:33:40 by CertMind
Updated 31 May 2022 14:34:30 by CertMind