Siempre intento mostrar el flujo de una Sprint Review y también me han intrigado las diferentes formas en que los equipos Scrum realizan sus revisiones de Sprint.
No es como si yo muestre una gran variedad de técnicas, y sugiero que los equipos simplemente elijan el formato que deseen.
Pero mi batalla de acompañamiento habitual es normalizar la práctica de tener un flujo en una Sprint Review.
Las revisiones de Sprint (Sprint Review) son lo último en lo que muchos equipos desean pensar.
Para el momento en que llega al final de una iteración, a menudo todavía tienen un trabajo perdido pidiendo atención al tablero de tareas.
El tiempo necesario para preparar y llevar a cabo otra “reunión Scrum” no suele considerarse una prioridad en tales condiciones.
Además, debemos lidiar con el deseo humano de pasar por alto e ignorar preferiblemente cualquier falla aparente o posible fuente de vergüenza.
El pronóstico realizado en Sprint Planning podría haber estado muy lejos, por ejemplo, y la oportunidad de volver a planificar en cada Daily Scrum podría no haberse tomado tan en serio como debería haber sido.
Cualquier compromiso con un Objetivo de Sprint que podría haberse evaporado con la salida del sol de la mañana.
En conclusión, el formato en el que los equipos Scrum realizan sus revisiones de Sprint puede ser tan variado como el trabajo en sí mismo y el resultado esperado de hacerlo.
Si los miembros del equipo se han centrado en la entrega de funciones, una “demostración” de alguna nueva capacidad podría ser la piedra angular del evento.
Si la atención se ha centrado más en el flujo, entonces el énfasis podría estar en las expectativas de nivel de servicio y cualquier métrica de producción asociada.
Por otra parte, el formato correcto para una revisión de Sprint puede estar en algún punto intermedio pero el flujo a seguir es el descrito en este artículo.
Lo importante es reconocer el propósito irreducible de realizar una Revisión de Sprint en primer lugar.
