¿Incrementos utilizables o útiles en Scrum?

Entonces, ¿PO necesita asistir a todas las demostraciones de Sprint?

El propietario del producto debe obtener visibilidad del trabajo realizado por el equipo a lo largo del sprint.

La intención de la ceremonia de revisión del sprint en Scrum no es informar al propietario del producto sobre el trabajo que ha realizado el equipo, sino informar a las partes interesadas que no están involucradas con el equipo día a día como lo está el propietario del producto.

Además, la revisión del sprint no es solo una demostración. Para citar de la Guía Scrum :

La Revisión del Sprint es una sesión de trabajo y el Equipo Scrum debe evitar limitarla a una presentación.

Si está utilizando Scrum, la expectativa es que el Equipo Scrum cree "un Incremento valioso y útil en cada Sprint". Antes de las revisiones de la Guía Scrum de noviembre de 2020, se usaba el término "potencialmente liberable".

No hay una "Demostración de Sprint" en Scrum. El evento es el Sprint Review. Una demostración puede ser un componente de una Revisión de Sprint, pero es más que una demostración. Una demostración puede ser una forma para que las partes interesadas revisen lo que se ha logrado en el Sprint, pero la Revisión del Sprint debe contener elementos en los que las partes interesadas discutan los cambios en el entorno y la Meta del producto y la Lista de pedidos del producto se ajusten en función de la información más reciente.

Si se necesitan "algunos Sprints" para implementar lo suficiente como para que los interesados ​​revisen el trabajo y obtengan retroalimentación, eso es indicativo de otros problemas. Sin embargo, no hay información suficiente para siquiera comenzar a comprender dónde podrían estar los problemas.

En pocas palabras , Scrum se explica así (énfasis mío):

1. Un Product Owner ordena el trabajo de un problema complejo en un Product Backlog.
2. El Equipo Scrum convierte una selección del trabajo en un Incremento de valor durante un Sprint.
3. El Equipo Scrum y sus partes interesadas inspeccionan los resultados y se ajustan para el próximo Sprint.
4. Repetir

La idea de ejecutar sprints es que los use como una cadencia mínima para entregar software que funcione, o al menos tener algo útil para inspeccionar al final del sprint. Este es el Incremento del producto (o un montón de incrementos si, por ejemplo, entrega más a lo largo del sprint mediante el uso de prácticas como Integración/Despliegue/Entrega Continua). A continuación, utiliza los incrementos para adaptar su estrategia y decidir qué trabajar a continuación o qué es importante a continuación. También aprovecha la oportunidad para hacer una retrospectiva para ver cómo también puede adaptar y mejorar la forma en que está trabajando.

Cuanto más espere para proporcionar algo útil, más largos serán los bucles de inspección y adaptación, y más problemas o riesgos pueden manifestarse antes de que pueda adaptarse.

He visto muchas empresas que desarrollan software y entregan valor utilizando un enfoque anticuado, como juntar cosas en hitos cada trimestre (en el mejor de los casos) usando mini cascadas, con diagramas de Gantt que presentan el trabajo en capas horizontales, con una etapa final para integrando todo el trabajo, etc., pero esperan que sus equipos hagan Scrum al mismo tiempo. Lo que pasa es que solo hacen que los desarrolladores trabajen en sprints, con un montón de reuniones que frustran a todos porque están vacías de sentido (ya que se sigue trabajando de la misma manera pero diferente), pero las reuniones se tienen que hacer porque Scrum dice eso Eso no es Scrum.

Si quieres hacer Scrum, trata de seguir sus reglas.

Si está haciendo otra cosa que funciona para usted y no le preocupan los riesgos o problemas que pueden ocurrir durante un gran esfuerzo de desarrollo con un largo ciclo de retroalimentación para igualar, entonces también está bien. Simplemente no lo llame Scrum y no obligue a las personas a participar en ceremonias que no tienen sentido por sí mismas, sin que las otras piezas encajen también.