Sprint Review

Facilitación Gráfica – Eventos en Scrum

¿Sabes qué es un Sprint o una Review? En este post de facilitación gráfica – Eventos en Scrum vamos a decirte qué es un evento y cuáles son.

Eventos, ¿para qué?

Scrum prescribe una serie de eventos que crean regularidad y evitan las reuniones no planificadas. Son un total de cinco eventos y todos ellos tienen un límite de tiempo. Estas reuniones planificadas nos permiten inspeccionar y adaptar cada poco tiempo, y facilitan la transparencia.

¿Cuáles son?

Los eventos que define Scrum son:

– Sprint (el que engloba el resto de eventos, un metaevento)
– Planning
– Daily
– Review
– Retrospective

En próximas entradas os iremos contando qué hacemos en cada uno de los eventos, quién debe asistir a cada uno de ellos y cuál es el time-box aproximado.

En Scrum se entrega solamente una vez cada Sprint

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.

You have been doing the Sprint Review all wrong

My clients ask me many questions, but one that I hear over and over is: Why isn’t Scrum working? or How do we improve quality with Scrum?. My answer seldom varies from: How are you using Scrum?

Sprint Review is one of the things that most organizations fail to do properly. In Scrum, it is the main business meeting. Simple mechanic: Product Owner hosts the meeting, taking as her primary responsibility expressing the value of what has been accomplished during the Sprint. Scrum Team answer questions about the increment so it can be inspected and adapted. Afterwards, Stakeholders take their chance to discuss with the PO and Dev Team which are the actual business conditions and update the Product Backlog.

So then problems begin. Product Owner cannot attend the Sprint Review. Stakeholders? Don’t make me laugh. Nobody knows or cares about business conditions. Development Team did not complete a Software increment. But Scrum is guilty.

It is interesting that with all those potholes in the organization’s capability to be competitive and give service to its customers, fault is on Scrum. Do you remember Costa Concordia, the cruise that sunk close to the Italian coast because the captain was trying to impress a escort. Yep, that could have been just the sea’s fault.

If you want to offer a delightful Sprint Review, think of:

Before the Sprint begun, there was a Sprint Goal to work against
Make sure the whole Scrum Team delivers a done increment
Stakeholders are invited and attend the Sprint Review (yay! No more need for status report meetings, those are the Sprint Review)
There is a conversation about what has gone well and wrong during the Sprint
At the end of the meeting, there is an updated Product Backlog and upcoming priorities are expressed according with business conditions.

Of course, if you are a Scrum Master and you are facing one of the situations described above, you might think:

But this is impossible, I cannot change the organization.

Well, then you might do better looking for a new job, because you may not last long. When we talk about removing impediments in Scrum, we talk about improving and shaping the organization towards adopting agility. We don’t talk about repairing keyboards for developers and arranging schedules.

The main difference between an experienced Scrum Master and a junior one is the capability to influence the organization without the authority to do so. That’s the main quality that makes a Scrum Master excellent.