¿Cómo han de ser los incrementos resultantes de un sprint?

Primero recordar que el incremento es la suma de todos los elementos de la pila de producto producida durante un sprint. Este debe de estar completamente terminado, ser operativo y ha de ser potencialmente entregable al cliente independientemente de que el Propietario del Producto decida o no liberarlo a producción.

Como terminado se entiende que el incremento se basa en un código probado, bien estructurado y bien escrito y que se ha compilado en un ejecutable. Si el proyecto o el sistema requieren documentación técnica, archivos de ayuda, documentación para el usuario, procesos de validación y verificación documentados u otros requisitos adicionales del producto, todo ello debe de estar hecho conforme se recoge en la definición de hecho (DoD).

Ilustración tarta a porciones, de Sabrosa Alquimia

Esto implica que la arquitectura y el entorno técnico para poder ejecutar ese incremento deben de estar incluidos, pero sólo lo necesario para el sprint y los anteriores. Por ejemplo cuando desarrollemos un primer incremento este debe de incluir lo necesario para que se pueda ejecutar, pero no mucho más allá. Quizá así incurramos en deuda técnica de escalabilidad, pero así nos focalizamos en nuestro incremento y construirmos sólo aquello donde la incertidumbre sea baja, lo que nos hace ser ágiles. Probablemente habremos de incluir la deuda técnica en un futuro sprint, pero cuando lleguemos, no antes.

Una forma de imaginarnos los incrementos de Scrum es como si construyéramos una tarta a partir de sus porciones. La idea es entregar porción (incremento) tras porción dónde cada una tiene una base de bizcocho (arquitectura, entorno técnico), su relleno (funcionalidades) y su decoración (documentación). Para que el incremento sea entregable es importantísimo que el repostero (el tester, uno de los miembros del equipo) la haya probado antes de exponerla a los clientes, no vaya a ser que algún ingrediente falte o sobre y la porción sepa mal.

Por tanto los incrementos han de ser lonchas verticales en la medida de lo posible, a diferencia del desarrollo de proyectos bajo metodología tradicional donde se suele planificar y desarrollar horizontalmente por capas (capa de base de datos, capa de negocio, capa de presentación...).

Siguiendo con la analogía de la repostería, la división vertical de un producto no sólo permite construir los incrementos guiados por valor, sino también nos da la oportunidad de ir adaptándonos hasta el punto de poder crear nuevas funcionalidades no previstas inicialmente, otros postres muy distintos, como los muffins por ejemplo, que son posibles a partir de los mismos ingredientes que tenemos disponibles.

Quiero dar mis agradecimientos a María por abrirme a la repostería y por la foto del post, a José López por algunas ideas como los muffins y a raq por el repostero y recordarme que la calidad no puede ser una variable en Agilidad.