Aceptación oficial de trabajo en el Sprint Review: ¿sí o no?

Algunos equipos utilizan el Sprint Review como una oportunidad para que el Product Owner o los stakeholders principales acepten los Product Backlog Items completados en ese Sprint.

En principio, un Sprint Review no debería ser utilizado por un equipo para que el Product Owner apruebe el trabajo. El equipo y el Product Owner deberían colaborar tan estrechamente durante el Sprint que el equipo ya sepa lo que el Product Owner piensa de su trabajo.

"Sin sorpresas" es mi primera regla para el Sprint Review

Es completamente aceptable que un Product Owner no acepte el trabajo del equipo para un determinado Product Backlog Item. Sin embargo, el equipo debería saber de antemano que eso va a suceder.

Los miembros del equipo no deberían entrar a un Sprint Review esperando un gran reconocimiento por su trabajo, solo para recibir quejas totalmente inesperadas.

¿Puede usarse el Sprint Review oficialmente para la aceptación?

Cuando un cliente contrata a un proveedor para desarrollar un producto, idealmente alguien en la empresa del cliente actúa como Product Owner. En este caso, puede estar bien que los features sean aprobados en el Sprint Review. Aún así, mantengo que no debería haber sorpresas en el Sprint Review.

Incluso si el Product Owner del cliente da feedback al equipo durante el Sprint, es posible que deba esperar a una aceptación oficial hasta que los demás stakeholders hayan tenido la oportunidad de opinar sobre el trabajo.

Un ejemplo sencillo

Un ejemplo sencillo: mi hija me preguntó hace poco si podía participar en una excursión escolar. Le dije que no tenía problema, pero – adivinen – primero teníamos que preguntarle a su madre. La razón era que mi esposa podría haber tenido otros planes familiares para esa fecha de los que yo aún no sabía.

¿Y la aceptación en un proyecto real?

Esta es una situación cotidiana para los Product Owners en proyectos de desarrollo. Aunque al Product Owner que interactúa diariamente con el equipo le guste cómo se construyó un feature, puede que aún necesite asegurarse de que los stakeholders a quienes representa también estén de acuerdo. Por supuesto, se podría argumentar que el Product Owner simplemente podría ir y preguntarles. Pero eso puede ser muy poco práctico y, por lo tanto, lo mejor es resolverlo en el Sprint Review.

En estos proyectos de desarrollo, el cliente no siempre proporciona un Product Owner. Frecuentemente, el cliente paga para que el proveedor se encargue de todo.

El cliente sigue siendo, por supuesto, el verdadero Product Owner. El cliente será quien finalmente acepte o rechace el trabajo de desarrollo. Sin embargo, no quiere ser "molestado" con estas cosas a diario. La solución típica es que el proveedor designe un Product Owner de su propia empresa.

Y en este caso, los Product Backlog Items no pueden ser aceptados antes del Sprint Review. El verdadero Product Owner (de la empresa del cliente) no está lo suficientemente disponible e involucrado como para poder aceptar trabajo con más frecuencia.

Ciertamente, el equipo puede obtener una aprobación preliminar de su propio Product Owner durante el Sprint. Pero el verdadero Product Owner de la empresa del cliente puede tomar una decisión completamente diferente en el Sprint Review.

La respuesta definitiva depende, como tantas veces, del contexto de cada situación. Por eso debo decir que no me preocupa demasiado si la aceptación oficial del trabajo ocurre en el Sprint Review. Aún así, sigo manteniendo que no debería haber sorpresas en el Sprint Review. Haz lo que mejor funcione para ti. Lo importante es que los miembros del equipo sepan antes del Review lo que les espera.

Este texto proviene del blog de Mike Cohn y fue traducido por nosotros al español.

Sprint Planning orientado a la velocidad

=> Ventajas y desventajas del Sprint Planning orientado a la velocidad

¿Cuándo cambiar el orden de los ítems?

=> Aquí hay 5 buenas razones por las que de vez en cuando se debe ajustar el orden de los ítems en el Sprint.