He visto y vivido ya unas cuantas Sprint Review, con agenda y sin agenda, de todos los sabores y colores, unas más centradas y otras menos, una más acertadas y otras menos, pero muy (muy) pocas que cumplan al 100% con el objetivo real de un evento tan importante, mostrar el incremento terminado, y recibir feedback.
Es por este motivo, el de que pocas cumplen con su objetivo al 100% por el que escribo este post, para intentar ayudar con una propuesta de agenda a aquellas personas que necesitan «una manita» con esto.
Lo que viene a continuación es tan solo una propuesta, la guía Scrum no especifica un formato/agenda concretos para la Sprint Review. A continuación los puntos que considero básicos:
El previo.
La convocatoria.
¿Quién debe asistir obligatoriamente? El Scrum Team (al completo), los stakeholders, y los usuarios, cualquiera que el PO considere de interés… demás personas como el Sponsor, alguien que pasaba por allí, un PO de otro producto, cualquiera, son bien recibidos.
No nos olvidemos de que la Review, es un evento al que puede acudir quien quiera.
Lo que no debiéramos permitir bajo ningún concepto, y de esto hablamos en los anti-patrones, es que la Review se convierta en una reunión de reporte y/o validación en la que el equipo presenta al PO y/o al SM lo que han hecho durante el Sprint.
La agenda.
Tener una agenda clara (algo que debería ser obligatorio en cualquier reunión o evento) que contemple como mínimo:
- La hora inicio y fin del evento
- Un descanso si lo viéramos necesario
- Los puntos que se van a abordar
Estos sencillos puntos, nos ayudan a manejar el time-boxing, las expectativas, a mantener el foco y a que todo el mundo sepa dónde está en cada momento. Si además, podemos incluirla en la convocatoria, pues mejor que mejor, que siempre hay algún despistado/a.
Del tema tiempos (puntualidad, respetarlos…) no vamos a hablar, que ya somos todos mayorcitos.
La Review.
Ahora si, vamos con la Review:
Introducción.
Que alguien realice una breve introducción siempre es de agradecer, dado que el evento es facilitado normalmente por el PO (en ocasiones por el SM), sería interesante que lo hicieran el/ella.
Si todos se conocen (los asistentes) bien, sino, no estaría de más una ronda rápida de presentaciones, nombre y rol suelen ser más que suficiente. Esto es algo bastante común cuando iniciamos el desarrollo de un nuevo producto.
Qué será y qué NO será mostrado.
Hemos trabajado durante todo un Sprint para alcanzar un Goal, para ello habremos abordado diferentes items del Sprint Backlog y es muy probable que hayamos creado nuevos y/o negociado alguno que entrase/saliese (siempre con el GOAL en mente).
Es bueno que el PO haga un breve repaso de los items que serán mostrados y cuales no, para ello será útil que contemos con algún apoyo visual. Una lista con una breve descripción y un indicador de si será mostrado en la demo, puede ser suficiente.
Contemos con que puede haber elementos que estén finalizados pero que no se muestren en la parte demo de la Review (ej. un ítem de migración de bbdd).
Esta lista de items puede ser útil a la hora de que los asistentes decidan si es interesante su asistencia (o no), por lo que puede ser útil facilitársela previamente. A nadie le gusta asistir a un evento en el que no hay «nada» que aportar, aunque todo feedback es bien recibido.
Analicemos los problemas.
Es importante que comentemos que ha ido bien durante el Sprint, los problemas que nos hemos encontrado y cómo los hemos resuelto (como equipo de desarrollo). Sin caer en analizar el proceso ya que estaríamos entrando en una retrospectiva, y no es el objetivo.
Demo.
Una de las partes más importantes de la Review, la demo. Es el propio equipo de desarrollo el que se encarga de esta parte, respondiendo a cualquiera de las preguntas u observaciones que cualquier asistente plantee sobre el incremento.
Recordemos que el principal foco de este evento es la recogida de feedback.
Ampliando el feedback con métricas.
Aunque en el momento de la Demo hemos recogido feedback, quizás nos interese ampliarlo algo más, o apoyarlo con más información. En este punto podemos incorporar métricas sobre el indice de adopción de nuevas features, impacto en mercado o sobre la cuenta de resultados.
Todo esto es información importante y que en muchas ocasiones vendrá dada por el PO, y debe tenerse en cuenta para los siguientes Sprints. Es el PO quien deba responsabilizarse de ver como «su» producto está impactando en el mercado y si está consiguiendo su objetivo.
También debemos analizar la información económica con respecto del Producto. Recordemos que el TCO es cosa del PO.
Revisión del Product Backlog.
De cara al siguiente o siguientes Sprint, y recogiendo el feedback que hemos recibido/tratado, revisaremos el Product Backlog.
En este punto podremos alterar el orden y/o priorización de determinados ítems o cambiar los próximos objetivos a alcanzar.
Este es un buen momento para realizar proyecciones o ver si el plan de releases (si contamos con el) se ve impactado por el feedback y el progreso hasta el momento.
La salida de la Review debe ser un Product Backlog revisado que define los potenciales items a bordar en el siguiente Sprint.
Cierre
Agradecer la asistencia de todos y su participación nunca está demás. Si evitaría los elogios particulares al esfuerzo de uno o todos los miembros del equipo, ya que esto puede generar ciertas dinámicas no necesariamente buenas más adelante.
Conclusión.
Lo expuesto en este post, no está recogido en la Scrum Guide, es tan solo una propuesta, que me ha resultado bastante útil, sobre todo cuando he trabajado en entornos nuevos o con ciertas «inercias» a corregir.
Que no sea algo que se describe de manera formal en la guía no quiere decir que no sea coherente con lo que la misma plantea 😉
Igual alguien ha llegado a este punto preguntándose ¿Y las métricas?¿Dónde están las métricas? Las métricas Benja! Entendiendo como métricas la velocidad, el número de items que aborda el equipo, el número de Pull Request realizadas… Aquí os va la métrica (software funcionando, y aportando valor):
Algunos artículos relacionados.
- An Agenda for the Sprint Review de Mountain Goat Software.
- Sprint Review (Spanish Edition) de Joel Francia.
- Sprint Review de KnowledgeHut Tutorials.
