Uno de los pilares de la teoría de control de procesos empíricos (empirismo) en que Scrum basa su secreto del éxito, es la Inspección. La Sprint Review da espacio y herramientas al equipo y a los interesados para hacer inspección de forma continua; y avanzar en el proyecto de la forma más constructiva y eficiente posible.
Podríamos entender la Review cómo la oportunidad del equipo para comprobar el norte. Al final de cada Sprint el equipo proporciona un incremento y lo muestra en la reunión de Sprint Retrospective. El Product Owner y los Stakeholders son protagonistas en esta reunión. Ya que el primero lidera la reunión. Y los segundos lideran la inspección y aceptación.
Este incremento que se somete a inspección ha de estar en situación de poder ser inspeccionado por los stakeholders. Esto significa diversas cosas importantes:
La Meta del Sprint (Sprint Goal) es un enunciado consensuado con el equipo, y definido cómo la primera acción en el Sprint Planning, que explica de forma comprensible que objetivo de valor busca conseguir el incremento que ahora entregamos. La Sprint Review ha de servir para comprobar que, efectivamente, el incremento da complimiento a aquella intención descrita en el Sprint Goal.
Los Stakeholders más relevantes e impactados en el incremento que entregamos han de estar presentes en la Review. Hacer entrega únicamente al Product Owner no es una buena práctica. Los Stakeholders, en la reunión de Review, generarán una sinergia de feedback que tiene mucho valor para el equipo.
El producto ha de cumplir el Definition of Done (DoD). Es decir, estar acabado tal como lo entiende la organización. El DoD lo explicamos en otro artículo, pero lo más importante es entender qué, acabado, no significa simplemente construido. Ha de cumplir todo aquello que sea necesario para poder explotar este incremento de forma inmediata. Y esto incluye aspectos muy relevantes cómo la documentación, el testing, la integración, la información para al mantenimiento, etc.
El incremento de producto a mostrar no puede basarse en una actividad de DEMO. Los Stakeholders han de poder tocar el incremento y practicarlo en un entorno realista. Solo así se puede crear un escenario de aceptación en qué verdaderamente es pone a prueba el producto.
La forma de poner a prueba el incremento es mediante los criterios de aceptación. Los criterios de aceptación para esta entrega, fueron definidos al inicio del Sprint, en el Sprint Planning. Los Stakeholders y el Product Owner son los responsables, tanto de la definición inicial de los criterios de aceptación, cómo después poner en práctica estos criterios para someter a prueba el incremento que entregamos en la Review.
Una ejecución satisfactoria de estos criterios de aceptación son un argumento de mucho peso, para poder tener la confianza que el equipo necesita en qué los stakeholders validan el incremento con fundamentos firmes.
La práctica nos dice que, tan importante cómo que los Stakeholders nos aceptan (o no) el incremento, es que estos nos den informaciones de primera mano que nos empoderen de cara a la búsqueda constante de la mejora. Especialmente importante es el feedback cuándo el incremento no puede ser aceptado por los Stakeholders. Pero aunque nos lo acepten, el feedback sigue siendo una finalidad primaria. En ocasiones, una aceptación no siempre es sinónimo de una conformidad al 100%.
Hemos de pedir este feedback y crear el ambiente idóneo en la reunión para que este feedback surja de forma natural.
Podemos ver la Sprint Review cómo dos reuniones en una. Una primera parte, de corta duración, donde el equipo empodera al Product Owner para qué este sea capaz de liderar la segunda parte de la reunión. En esta primera parte explicamos al Product Owner la situación final del Sprint, y los pequeños detalles que puedan ser interesantes para el Product Owner.
Esta parte nunca debe tener el objetivo de explicar al Product Owner un gran problema en el Sprint. En general, los problemas que aparecen durante el Sprint se tratan de forma inmediata, con las personas que han de estar informadas y las que nos han de ayudar a resolver el problema en cuestión. No podemos esperar a una Review para explicar un problema al Product Owner. Si estamos en esta situación hemos de realizar una dinámica de Retrospectiva para hallar mejoras en lo referente a la comunicación.
La Review no debería consistir únicamente en la ilustración del incremento. Deberíamos ser capaces de mostrar a los Stakeholders la experiencia vivida durante el Sprint. Las anécdotas buenas y no tan buenas ocurridas. Comentarios de valor sobre cómo el equipo técnico vive la evolución del proyecto. Sobre el volumen de trabajo que podemos resolver. O cualquier otro comentario no necesariamente relacionado con el producto, que pueda ser útil.
La Transparencia, otro de los pilares de la teoría de control de procesos empíricos, sería el aspecto que también tiene cabida en la Sprint Review.
| El PO egoísta | El PO es el único aceptador | Muerte por PowerPoint |
|---|---|---|
| El PO presenta los éxitos y el valor como suyo. Los éxitos y los fracasos son siempre del equipo | El PO acepta en nombre de los stakeholders. No se favorece el contacto con los stakeholders ni su feedback. La aceptación del PO no se produce siempre por el valor obtenido y el cumplimiento del DoD | En la Sprint Review se usan presentaciones, y no el producto |
| Siempre las mismas caras | No se informa al PO | ¿Qué es el DoD? |
|---|---|---|
| No hay variedad entre los interesados del producto. Siempre se presentan a la Review los mismos, aunque no siempre les impacta a ellos el valor obtenido | Los developers realizan acciones no previstas y/o no obtienen los resultados previstos. Y lo comunican al PO en la Review | Los técnicos no conocen o no acatan el DoD establecido, y presentan como Done resultados que no lo están |
| Sprint Review Planning | Sprint Review de tareas | |
|---|---|---|
| Se usa la Sprint Review más para planificar trabajo que para presentar resultados y obtener feedback y aceptación | Se usa la Sprint Review para un repaso del desempeño al por menor de cada tarea técnica, olvidando que lo relevante es el valor obtenido y su utilidad para el negocio |
Descarga el esquema para imprimir aquí
