¿Quién presenta el incremento en la revisión de sprint?

Miembro del equipo presentando el incremento en la
revisión de sprint - cortesía de Pixabay

A lo largo de diferentes equipos he visto distintas configuraciones que dan distintas respuestas a esta pregunta.

Nos encontramos en la revisión de sprint donde, según el marco de Scrum, el equipo es quien enseña lo que ha realizado a lo largo de del sprint. Primero expone el objetivo del sprint para después demostrar el funcionamiento de lo que ha completado al 100%, aquello que entrega y cumple con la definición de hecho (DoD).

Usualmente se recorren una a una las historia de usuario de la pila de sprint, se explica como se abordó cada una de ellas y se demuestra el funcionamiento en un entorno que represente entrega (test, staging, preproducción...). Tratada la historia en curso se pasa a la siguiente. Pero, ¿quién se sienta ante el ordenador y demuestra el software funcionando e interlocuta con los interesados?

La respuesta es el equipo de desarrollo, y es una preferencia del equipo como hacerlo, a veces hay un voluntario, a veces se nomina un presentador de entre los miembros y a veces lo hacen de forma compartida. He visto varias configuraciones que funcionan:

• El tester hace de presentador: es una opción que funciona muy bien porque el tester habrá efectuado las pruebas a lo largo del sprint, tiene la visión del incremento fresca en su memoria, y por la naturaleza de su especialidad está mas cerca de los usuarios para los que se está construyendo el producto.
• Un líder que emerge del equipo: siempre suele haber un voluntario con habilidades sociales al que le guste mover cosas y tratar con otras personas. Suele tener más empatía y más comprensión del la solución a nivel holístico.
• Algunos miembros de forma rotatoria: es una opción que funciona cuando no es obligatoria para todos los miembros, funciona solo si rotan aquellos miembros del equipo que quieran hacerlo de forma voluntaria. Una revisión de sprint presentada por un miembro que siente que no puede hacerlo, o no quiere hacerlo, probablemente resulte en una reunión pobre que genere un feedback escaso.

En mi experiencia la mejor combinación es cuando una persona presenta y lleva la conversación con los interesados, y otra persona ejecuta la demostraciones de las funcionalidades en el ordenador. Si además intervienen otros miembros cuando sienten que tienen algo que puedan aportar tenemos la mejor de las opciones posibles

Como siempre suele ser con Scrum, para saber si tenemos una reunión exitosa basta con fijarnos en como interactúan las personas, si el campo emocional es de "buen rollo", las personas hablan como iguales, con respeto y seguras y sin miedo a equivocarse, entonces podemos estar seguros que todo está bien encarrilado.