Este artículo forma parte de una serie en la que revisamos los fundamentos de Scrum complementados con infografías que los explican. Otros artículos: Sprint, Planificación, Daily, Review, Retrospectiva, Product Owner y Scrum Master, Developers o Backlogs.

Autores: Alonso Álvarez y Patricia Parreira. 

Le podemos dar muchas vueltas, pero al final Scrum es un marco que ayuda “a generar valor a través de soluciones adaptables para problemas complejos”. Esta definición, la de la guía oficial, nos dice que mejor no usarlo para problemas simples, repetitivos, predecibles: sería una complicación innecesaria. Por otro lado, las soluciones que nos ayuda a obtener Scrum son “adaptables”, lo que es una ventaja en el contexto inestable y frenético en el que vivimos. Esta definición nos ayuda también a descartar muchos posibles problemas en los que Scrum no tendría aplicación. 

Así que Scrum tiene sentido para encontrar soluciones a determinados problemas, pero siempre con la vista puesta en la generación de valor. Vamos a ver qué valor es ese. 

El Incremento de producto es el tercero de los tres artefactos definidos por Scrum, junto a los backlogs de producto y de Sprint. El Incremento es el mecanismo para ofrecer valor por medio del proceso Scrum, y lo único que se le pide es que sea “utilizable” (usable en la versión original). Pero el incremento no surge espontáneamente, si no que nace para cumplir el Objetivo del Producto. 

El Objetivo del Producto

Si recordamos lo hablado sobre la Planificación y los Backlogs, el trabajo con Scrum está guiado por un Objetivo del Producto definido y comunicado por el/la Product Owner. Este Objetivo marca el rumbo del trabajo del equipo, define qué contiene su backlog, condiciona el objetivo de cada Sprint… Es la brújula que guía toda la actividad, y también la forma de definir qué valor se busca obtener. 

Por ese motivo, el Incremento de producto, o más bien la solución que conforma la suma de los distintos incrementos, debe estar alineada con ese Objetivo. Pero no pensemos que con cada Incremento lo que hacemos es realizar una construcción secuencial y puramente incremental del producto. Si nos acordamos de la definición del inicio, se trata de generar valor con soluciones adaptables, lo que quiere decir que a medida que progresamos en el descubrimiento de qué quiere y -sobre todo- qué necesita nuestro cliente, puede que tengamos que cambiar el rumbo, incluso desandar el camino.  

Scrum está especialmente indicado para la construcción de productos y servicios que tienen una continuidad en el tiempo, frente a los proyectos con un alcance y, sobre todo, un tiempo y esfuerzo finitos. En la vida de un producto pueden pasar muchas cosas que lleven a eliminar o modificar aspectos, características o funcionalidades por un cambio en las necesidades, en los gustos o en el contexto (por ejemplo, la regulación). El objetivo es un destino normalmente estable pero no necesariamente estático. 

El Incremento es un paso concreto (no “de cemento” como aparece en la traducción española de la Guía Scrum) hacia el Objetivo del Producto. Cada paso supone un aprendizaje, por lo que el Incremento es además un vehículo para la inspección y adaptación al permitir obtener feedback de clientes y usuarios y con él generar aprendizajes e introducir ajustes. 

Es importante destacar que el Incremento no es algo que se entrega o libera únicamente al final del Sprint. Aunque es cierto que la revisión final se hace sobre el conjunto del trabajo realizado, nada impide hacer una entrega previa del valor generado durante el Sprint si es necesario. Si los interesados o stakeholders lo necesitan antes y está disponible ¿Por qué no hacérselo llegar? 

DoD

En Scrum hay definidos tres artefactos: Backlog de producto, Backlog de Sprint e Incremento de producto. Cada uno de estos artefactos tiene unos compromisos asociados: Objetivo de Producto y objetivo de Sprint son los de los dos backlogs respectivamente. 

El compromiso específico del Incremento de Producto es el DoD (Definition of Done, o Definición de Hecho). 

Se trata de una serie de criterios que, aplicados sobre el trabajo completado, permiten decidir si forma parte o no del Incremento. Es decir, aunque se haya trabajado durante el Sprint en alguna característica, necesidad o funcionalidad, sólo podrá acabar formando parte del Incremento que se entrega si cumple con los criterios que se hayan fijado. 

El DoD es “una descripción formal del estado del Incremento cuando cumple con las 
medidas de calidad requeridas para el producto”. Es la forma de determinar si un trabajo forma parte o no del incremento, no sólo el hecho de haberse llevado a cabo durante el Sprint. 

Este DoD deber ser conocido por todas las personas del equipo, es una forma de fomentar la transparencia, uno de los pilares de Scrum. Es también una forma entender por qué un resultado del trabajo acaba formando parte o no del Incremento. Estrictamente, y según la Guía, si un elemento de trabajo no cumple con el DoD, vuelve al estado de trabajo pendiente y ni siquiera se presenta en la Review o revisión al final del Sprint. 

Siempre debería haber un DoD conocido por todas las personas del equipo. Puede ser que haya uno definido de forma estandarizada por la organización. En ese caso el equipo Scrum deberá seguirlo, como el resto de equipos. Si no hubiera, el equipo debería definir el suyo propio. Si varios equipos trabajan en un mismo producto o servicio, deben aplicar un DoD común. 

Aunque en la Guía no se dan detalles al respecto, la práctica más habitual es usar una checklist o lista de comprobación para crear el DoD. Una checklist es una forma simple y explícita de asegurarnos que se han cumplido con una serie de criterios o se han ejecutado una serie de pasos. Incluso aunque sean sobradamente conocidos, incluso obvios, el hacerlo explícito con una checklist evita el impacto de olvidar o pasar por alto un paso o hecho importante. 

El DoD debería centrarse sobre todo en la calidad y funcionar como un criterio de aceptación general sobre el trabajo, aunque cada unidad de trabajo pueda tener criterios adicionales específicos. 

Aunque el DoD se mencione como parte de Scrum, no es en absoluto un mecanismo exclusivo de este marco de trabajo, y puede aplicarse en todo tipo de circunstancias en los que sea necesario garantizar una calidad mínima del trabajo realizado. 

Y, de propina… el DoR

DoR, Definition of Ready o Definición de listo, es la otra cara de la moneda. No forma parte de la definición de Scrum pero, como se verá, se puede aplicar igualmente. 

Se trata de una checklist que, en este caso, nos dice si estamos en condiciones de abordar una tarea determinada. Es una lista de comprobación preliminar. Es algo parecido a lo que se hace antes de un vuelo: se revisan determinados parámetros del avión antes de asegurarse de que está todo en orden para despegar. 

¿Qué uso se le puede dar a un DoR?

Por ejemplo, puede ser la lista de comprobación para asegurarse que tenemos todo listo antes de iniciar la reunión (material distribuido de antemano, personas convocadas, objetivos fijados, sala o medios reservados, …). También puede ser la lista de condiciones que debe cumplir una unidad de trabajo para poder abordarla (trazabilidad, documentada suficientemente, alineada con el Objetivo de producto, estimada, …). 

El DoR se usa mucho menos que el DoD y puede tener una mayor variabilidad, pero puede ser de ayuda en ciertas circunstancias: por ejemplo, si observamos que sistemáticamente hay falta de preparación antes de realizar algún tipo de actividad, o si hay esperas o bloqueos por falta de información o algún requisito para iniciar un trabajo. 

Esta idea del DoR y el DoD tiene además aplicación más allá de Scrum. Al igual que otros conceptos de este marco (la sincronización diaria, el uso de backlogs, las retrospectivas) pueden ser herramientas muy útiles en otras circunstancias 

Descargar Infografía completa

¿Quieres conocer más prácticas Scrum?

Te recomendamos la formación “Agile Fundamentals”, un curso de 24h para empezar a aprender los conocimiento y habilidades de Scrum y Kanban, acreditado por ICAgile.

IR AL CURSO Agile fundamentals