En Scrum existe un mecanismo que permite que el producto evolucione en entornos complejos: el modelo adaptativo de control a nivel de producto. Si lideras un equipo ágil o eres Scrum Master, entender cómo se aplican la transparencia, la inspección y la adaptación al producto te ayudará a evitar las malas prácticas más comunes en sprint reviews y plannings.

¿Cómo se logra transparencia a nivel de producto en Scrum?

La transparencia significa que la información del producto sea visible y accesible para todos en la organización. Scrum la provee a través de dos artefactos específicos.

El primero es el product backlog, la lista de todas las potenciales características o elementos que se podrían incorporar al producto. Funciona como una ventana al futuro de lo que vas a construir, y por eso debe estar abierto a toda la organización. Mantenerlo oculto, en manos exclusivas del product owner o del Scrum team, es una mala práctica que rompe el principio de transparencia.

El segundo artefacto es el incremento de producto, eso que el equipo construyó durante el sprint y que se muestra en la sprint review. Ahí se hace tangible el trabajo realizado.

¿Qué es el product backlog? Es la lista priorizada de todas las características potenciales del producto. Debe ser visible para toda la organización, no solo para el equipo Scrum.

¿Dónde ocurre la inspección del producto y por qué no es un PowerPoint?

La inspección es el proceso de analizar información para tomar decisiones, y a nivel de producto ocurre en la sprint review. El propio nombre lo sugiere: revisión del sprint.

Aquí aparece una de las malas prácticas más extendidas. Muchos equipos usan la sprint review como un espacio de seguimiento y control: llegan con diapositivas mostrando cuántos PBI cerraron, cuántos puntos de historia completaron o cuántas historias de usuario terminaron. Eso es comando y control, propio de los modelos predictivos, no del adaptativo.

El verdadero objetivo de la sprint review es inspeccionar el incremento de producto. Para que esto ocurra, los stakeholders, clientes y usuarios tienen que estar presentes e interactuar con el producto. Esa interacción es la que genera feedback real.

Cuando un equipo de software presenta un diagrama de arquitectura o de componentes, el cliente solo puede preguntar "¿vamos bien?". No tiene cómo dar retroalimentación útil. La inspección no se hace mirando un dibujo, se hace tocando el producto.

¿Qué tipos de feedback puedes recibir del cliente?

Cuando el cliente interactúa con el incremento, llegan dos tipos de información:

• Feedback directo: lo que el cliente dice abiertamente, como "esto me funcionó", "esto me está faltando" o "me confundí con esto".
• Feedback indirecto: el lenguaje corporal y los comportamientos no esperados, por ejemplo cuando el cliente hace clic donde no debía hacerlo.
• Señales de usabilidad: caminos espontáneos que toma el usuario y que revelan si el mensaje o la interfaz son claros.

Ese feedback indirecto suele decirte más sobre la usabilidad que cualquier comentario explícito.

¿Cómo se aplica la adaptación del producto en Scrum?

La adaptación es qué haces con la información obtenida en la inspección. Si viste que el cliente se fue por un camino que no esperabas, quizá el mensaje no era claro y un accionable concreto puede ser mejorar las instrucciones o ajustar la interfaz para reducir la confusión.

Esas decisiones sobre cómo mejorar el producto en los siguientes incrementos ocurren en la sprint planning. La sprint planning trata de definir qué se va a hacer en el próximo sprint para que el incremento genere más valor al cliente.

¿Cuál es la diferencia entre sprint review y sprint planning en el modelo adaptativo? En la sprint review inspeccionas el incremento con el cliente. En la sprint planning adaptas el producto decidiendo qué construir en el siguiente sprint.

¿Qué tres elementos forman el modelo adaptativo de control a nivel de producto?

Resumiendo lo que vimos, el modelo adaptativo de control de producto en Scrum se sostiene en tres pilares:

1. Transparencia, a través del product backlog y el incremento.
2. Inspección, a través de la sprint review con interacción real del cliente.
3. Adaptación, a través de las decisiones tomadas en la sprint planning.

Cuando alguno de estos elementos no cumple su propósito, ahí tienes como Scrum Master un trabajo claro por hacer: devolverle al evento o al artefacto la función para la que fue creado.

¿En tu equipo la sprint review se parece más a una demo con cliente interactuando o a un status report con diapositivas? Cuéntame en los comentarios cómo lo están manejando.