TL;DR

Scrum requiere que el evento se lleve a cabo al final de cada iteración, incluso al comienzo de un proyecto. Si bien podría considerar acortarlo o cambiar el enfoque ligeramente hacia el proceso en lugar de los entregables, el evento aún debe realizarse.

Cadencia de generación de eventos

Formalmente, Sprint Review es un evento obligatorio en Scrum. Si bien es razonable que sea breve si tiene poco que demostrar, es importante establecer el tono para una cadencia confiable desde el principio. Esta cadencia crea:

1. Previsibilidad. Las partes interesadas pueden confiar en tener un punto de inspección disponible en cada iteración.
2. Transparencia. Las partes interesadas pueden estar seguras de que tendrán una visibilidad clara del proyecto en cada punto de inspección, no solo cuando hay buenas noticias para compartir.

Entonces, incluso si no tiene nada que mostrar por sus esfuerzos (y lo tiene, así que siga leyendo), vale la pena realizar el evento.

Valor adicional

Incluso cuando no tenga algo que demostrar, una breve Revisión del Sprint es útil para invitar a la colaboración con las partes interesadas. La Guía Scrum proporciona algunos ejemplos claros de lo que debe contener una Revisión de Sprint además de demostrar los entregables:

• El propietario del producto analiza la cartera de productos tal como está. Él o ella proyecta probables fechas objetivo y de entrega en función del progreso hasta la fecha (si es necesario);
• Todo el grupo colabora en qué hacer a continuación, de modo que Sprint Review proporcione información valiosa para la planificación de Sprint posterior;
• Revisión de cómo el mercado o el uso potencial del producto podría haber cambiado qué es lo más valioso que se puede hacer a continuación; y,
• Revisión de la línea de tiempo, el presupuesto, las capacidades potenciales y el mercado para los próximos lanzamientos anticipados de funcionalidad o capacidad del producto.

Entonces, además de establecer una cadencia e infundir un sentido de confianza en las partes interesadas a través de la previsibilidad y la transparencia, ¡Sprint Review invita a la colaboración estructurada con el Equipo Scrum!

Cosas que puedes demostrar

Por supuesto, es posible que no pueda demostrar un incremento de producto . Pero si lo piensa, aún puede demostrar el valor del proyecto, ¡especialmente si ha adoptado una mentalidad ágil de prueba primero!

Por ejemplo, se puede demostrar la configuración de un entorno de desarrollador o un servidor de integración continua. ¿Sus desarrolladores usan un IDE? Tome un proyector y haga una demostración de las características de Intellisense (o lo que sea) que presumiblemente agregará valor al proyecto a través de la eficiencia del desarrollador. Sea breve, ¡pero explique por qué es importante!

¿Consiguió la integración continua en funcionamiento? Apuesto a que los miembros del equipo que lo hicieron lo probaron de alguna manera. Incluso si aún no están bombeando incrementos de productos, deben haber hecho algo para asegurarse de que funcione como se esperaba. Haga una demostración visual de eso y explique cómo esta característica orientada al equipo ayudará a entregar el producto que en última instancia interesa a las partes interesadas.

Confesiones del mundo real

Admitiré haber cancelado una Revisión de Sprint de vez en cuando, especialmente al principio o al final de un proyecto. Sin embargo, siempre he visto hacer esto como un fracaso de la imaginación, o el resultado de un enfoque demasiado orientado a las especificaciones (en lugar de las pruebas) del proyecto y su metodología de desarrollo de productos.

Si realmente no puede demostrar nada y no tiene nada en lo que las partes interesadas puedan querer colaborar, entonces ciertamente no quiere hacer perder el tiempo a todos. En tales circunstancias, podría tener sentido limitar la Revisión del Sprint solo al Equipo Scrum (incluido el Dueño del Producto). Solo asegúrese de establecer expectativas razonables sobre cuándo comenzarán en serio las Revisiones de Sprint, y asegúrese de comunicar cualquier valor que su Sprint haya brindado al Product Owner y a las partes interesadas.

En la etapa inicial de un proyecto, incluso cuando no he realizado una revisión de Sprint formal, por lo general he realizado un evento informal para discutir el alcance, la metodología o el enfoque del proyecto. Esto ha sido típicamente bien recibido.

Hacia el final de la cola, generalmente hay más para mostrar en cuanto al producto. Sin embargo, a veces las partes interesadas están menos interesadas en los cambios pequeños e incrementales en esa etapa del proyecto. En esos casos, a veces he sustituido reuniones más breves con las partes interesadas por la Revisión del Sprint formal. Allí, a menudo hablamos sobre cronogramas, fechas de envío o temas de cierre de proyectos.

No afirmo que sea una mejor práctica, y ciertamente no afirmo que sea Scrum. Sin embargo, ciertamente es una opción si no se desea un cumplimiento estricto del marco, o cuando la inmadurez del proceso o la apatía de las partes interesadas hacen que comenzar (o mantener) la cadencia no sea práctico.

Mi experiencia en el mundo real es que acortar el evento o cambiar el enfoque ligeramente hacia el proceso puede ser beneficioso en algunas circunstancias. Sin embargo, saltarme el evento por completo casi siempre ha sido un olor a proyecto para mí. No lo recomiendo, pero su kilometraje puede variar.

¡Sí! Mi recomendación en realidad sería tener una meta muy pequeña que sea fácil de ver, pero que no agregue mucho trabajo (o tal vez valor). Es más un tema de conversación que otra cosa. Esa primera revisión es un buen momento para preparar el escenario para el proyecto y presentar a las personas. No tiene que llenar el cuadro de tiempo, pero es una excelente manera sin estrés de comenzar las cosas con el pie derecho.

historias de usuarios arquitectónicas sin valor comercial

Animo a los equipos a crear una primera historia de usuario de estilo 'hola mundo' muy simple que ofrezca un valor comercial limitado pero distinto de cero. Luego, realice todas las tareas de configuración técnica en esa historia de usuario.

El beneficio de este enfoque es que hace que el equipo tenga la mentalidad de centrarse siempre en la entrega de valor comercial y deja en claro que las tareas técnicas son solo un medio para un fin.

Como ejemplo, un equipo de Business Intelligence con el que trabajé creó una primera historia:

Como gerente de marketing, quiero ver la fecha del informe de registro para saber cuándo se produjo

Luego, el equipo realizó todas las tareas de configuración y produjo un informe en línea muy simple que incluía la fecha actual y nada más. Esta primera historia tomó la totalidad de un sprint de dos semanas debido a todo el trabajo de configuración que incluyó.