La aceptación de los PBIs en Scrum es algo que suscita dudas en los equipos. En realidad es muy fácil.
En Scrum tenemos cuatro eventos y un metaevento. Los eventos son el Sprint Planning, Daily Scrum, Sprint Review y Retrospectiva. El metaevento es el Sprint, que es un contenedor para todos los demás.
Durante el Sprint Planning, seleccionamos los PBIs que queremos completar durante ese Sprint y trazamos un Sprint Goal que marcará la dirección de lo que queremos conseguir en ese Sprint. Una vez que vayamos trabajando en ellos, colaboramos con el Product Owner para que los validarlos. Los entregámos de acuerdo con nuestra Definition of Done tan pronto como estén validados.
En algunas organizaciones es más difícil, porque dependen de un proceso manual auditado de subida a producción, pero en aquellas que utilizan DevOps, tan pronto como se cumplen los criterios que tengamos establecidos, será un sistema automatizado el que se encarga de subir a producción. Una vez que esté hecho, los PBIs son aceptados.
Lo que no hay que hacer nunca es esperar hasta el Sprint Review para entregar los PBIs. Esto provoca una espera innecesaria. En cuanto el Product Owner los valida, deberían entrar en el pipeline de puesta en producción.
Poner en Producción y hacer una release
¿Que ocurre si los PBIs que hemos seleccionado en el Sprint no queremos ponerlos en producción? Esta es una cuestión de configuración. En Scrum, el concepto de “En Producción” y “Released” son distintos. El uso de herramientas que permitan hacer toggling feature permite tener software en producción y configurarlo a gusto del Product Owner.
Puede ser que hoy estemos haciendo elementos para la próxima campaña de Navidad. Este Software puede estar terminado y subido a producción pero no activado a ojos del usuario, lo cual nos permite también ver como se comporta y hacer cuantas modificaciones necesitemos sin correr tanto riesgo como en un sistema de despliegue tradicional.
Además, esta estrategia nos permite tener una Definition of Done más completa que incluya “puesta en producción” aunque sigamos trabajando en los elementos durante más tiempo, haciendo el desarrollo iterativo e incremental. Ante la duda, no, esperar a tener toda una nueva funcionalidad para ponerla en producción no es iterativo e incremental. Es más Waterfall.
En Scrum los PBIs se entregan tan pronto están finalizados, independientemente de si hemos llegado al Sprint Review o no. Nos permite desacoplar la entrega de los eventos. Así éstos se centren más en la estrategia de nuestro producto en lugar de en el funcionamiento técnico. O una demo.
Para validar el valor del Software realizado, esta vez sí, el Product Owner debería de buscar hacer una release cuanto antes.
Puedes leer más sobre como conseguir un buen Sprint Review en este artículo del blog.
