Con frecuencia en las clases he escuchado la siguiente frase: «en la reunión de Sprint Review, el Product Owner acepta o rechaza el Incremento de Producto desarrollado por el equipo en la Sprint».
Siempre que escucho esta frase, paro todo y empiezo una larga conversación con los alumnos para poner las cosas en su sitio.
Al trabajar como Product Owner desde 2008, me parece muy extraño que esta frase aún se diga por ahí como si el papel del equipo en la reunión de Sprint Review fuera conseguir la aprobación del Product Owner para los ítems desarrollados. Esa idea revela además otras disfunciones que normalmente permanecen ocultas en el equipo.
Así que, vamos por partes:
- Para empezar la conversación, es necesario recordar que un PO que se precie se sienta con el equipo durante la Sprint. Entonces, si el PO está ahí con el equipo, ¿por qué demonios no decide echar un vistazo a lo que el equipo ha producido hasta la Sprint Review?. ¿Por qué el PO no aprovecha la proximidad con el equipo y colabora a lo largo de la Sprint para ver cómo van las cosas y aprovechar para ayudar al equipo a fomentar pequeños ajustes en el rumbo? Pero atención: ¡ el PO está allí para colaborar! No para reclamar, exigir, cambiar todo, dárselas de jefe y ser Pepito Grillo.
- Otro punto es el de la definición de «Hecho» (definition of "Done"). Definition of "Done" (DoD) es un acuerdo entre los miembros del Equipo de Desarrollo y el Product Owner sobre lo que significa «Hecho». Si tienes una buena DoD, bien construida y fruto de mucho debate entre todos, debería ser suficiente para que el Equipo de Desarrollo pueda decir que algo está hecho. Entonces, ¿por qué el Product Owner tendría que hacer un double check? ¡Esto no tiene ningún sentido! Y hay más: si la definición de «Hecho» no está bien hecha o no es suficiente, ¿qué tal usar la Retrospectiva para revisar y adaptar?
- El último punto es: en la Sprint Review el Product Owner invita a los stakeholders más importantes/relevantes para que sea posible dar visibilidad sobre la evolución del trabajo y principalmente reunir su feedback (ver nuestro post «Review: ¿aprobación o feedback?»). Así pues, ¿qué sentido tiene esperar a que el cliente aparezca para decir delante de él que algo no está bien? ¿No habría sido mucho mejor ajustar las cosas durante el desarrollo y tener más valor que mostrar en la Review?
El hecho es que el Product Owner que no aparece hasta la Sprint Review y encima critica el trabajo del Equipo delante del cliente acaba demostrando que no ha cumplido con su parte durante la Sprint. Entonces, amigo PO, si quieres saber si estás haciendo tu trabajo bien o no, propongo un test rápido: si estás en una Sprint Review y lo que el equipo está presentando es una sorpresa para ti... ¡bingo! Eres un Product Owner ausente y esto puede generar una serie de disfunciones que acaban dificultando la vida de todo el mundo.
Y, para finalizar, quiero dejar esto bien claro: el Product Owner forma parte del Equipo, sí. Un Product Owner de verdad se sienta con el equipo, celebra y sufre con el equipo y por supuesto, participa en la Retrospectiva, ya que la mejora continua es para todo el Equipo de Scrum y no solo para el Equipo de Desarrollo, como muchos pregonan por ahí todavía. Pero bueno... ¡esto es tema de un próximo post!
Click here to read this post in English.
