En anteriores posts hemos repasado los diferentes artefactos que podemos encontrar bajo el framework Scrum (aquí puedes leer el post sobre el Product Backlog y aquí el correspondiente sobre el Sprint Backlog). Para terminar la serie nos falta uno más, pero no menos importante: el incremento en Scrum.
Qué vas as ver en esta entrada
¿Qué es un incremento en Scrum?
Basándonos en la última versión de Scrum (2020) se puede ver el incremento como un paso en el camino de conseguir nuestro ansiado Product Goal (u objetivo de producto). Cada incremento nos permite estar un paso más cerca de cubrir las necesidades de nuestros usuarios. Es por ello, que cada incremento se suma a los anteriores que han sido verificados. De esta forma potenciaremos el espíritu empírico que buscamos.
Definition of Done
Pero, ¿cómo aseguramos que un item del product backlog se convierte en un incremento? Fácil, debe cumplir la definición de «hecho» (Definition of Done o, como también se conoce, el DoD) acordada y consensuada por el equipo. Sobre el Definition of Done hablaremos en un post aparte en detalle pero, básicamente, es una lista de criterios acordadas por el equipo Scrum sobre qué debe cumplir un item para darlo por terminado.
Nunca debemos olvidar uno de los doce principios del Agile Manifesto donde se nos indica que la principal medida de progreso debe ser software funcionando. Por esa razón, la guía Scrum nos indica que un incremento debe ser utilizable.
El DoD debe ser frecuentemente revisado y, repito, consensuado por todo el equipo. Lo ideal es asegurar y aumentar la calidad de nuestras entregas y en estas revisiones se busca ampliar, poco a poco, nuestra definición de hecho con más criterios (también, se puede dar eliminar criterios por quedarse obsoletos, adaptándonos así al contexto).
Lo más frecuente es que durante un Sprint se entreguen o liberen varios incrementos. Todos estos se mostrarán en la Sprint Review a los stakeholders, los cuales, nos darán feedback. Feedback que nos ayudará a refinar los próximos incrementos. La Review nunca debe ser un punto donde se valide o libere diferentes incrementos, si llegan a este punto, es que cumplen la DoD.
¿Qué relación tiene un Product Owner con el incremento?
Según casuística, es el encargado de decidir si liberar o no los incrementos (según cada caso puede ser un despliegue a producción, abrir o no cierta funcionalidad a los usuarios, realizar tests A/B, etc). Debe poseer los conocimientos y autoridad suficiente para poder decidirlo.
El Product Owner también tiene la responsabilidad, junto con el Scrum Master, de conseguir que la ejecución de tareas de desarrollo sobre un incremento no se vean bloqueadas y vayan avanzando.
Siguiendo con los principios del Agile Manifesto lo ideal es entregar software con mucha frecuencia y conseguir feedback muy rápido. Ello nos dará mayor información sobre cómo llegar a ese Product Goal que comentábamos al inicio.
Para ello es necesario que trabaje codo a codo con el equipo de desarrollo solventando dudas (hay equipos que aprovechan la daily para aclarar cuestiones que atañen al Sprint Goal), aclarando información y, llegado el caso, reajustar el incremento para que case con el contexto actual.
Desde mi punto de vista puede verse que un incremento pasa por diferentes estados desde que nace como una idea o necesidad, pasa por los diferentes backlogs hasta convertirse en un incremento. Y durante todo este proceso intervienen en diferentes fases todas las personas del equipo Scrum.
Caso práctico: posts sobre artefactos Scrum
Para terminar, veamos un caso práctico con la publicación de este post. Mi objetivo de producto era crear contenido sobre los artefactos de Scrum. Este objetivo ha sido dividido en tres items del backlog, uno por cada artefacto. Como hemos comentado anteriormente, para que estos items se considerasen incremento tienen que cumplir mi Definition of Done. En esta yo he incluido entre otros criterios que sea publicado («desplegado en producción»).
Con el primer incremento, ya estábamos un poquito más cerca del objetivo final. Un 33% de hecho (porque sí, esto nos ayuda también a medir el software que entregamos). Con el segundo post, damos un paso más de nuevo, llegando al 66%. Como Product Owner que quiere entregar frecuentemente he decidido que conforme pase la validación, estos posts vayan a PRO. Y con este último post que estás leyendo, hemos conseguido llegar a nuestro Product Goal satisfactoriamente.
Por ello siempre es importante tener foco en el objetivo, nos guiará por el camino.
