¿Qué es el Increment en Scrum?

Índice

¿Qué es el Increment en Scrum?

El Increment (“Incremento” en español) o también conocido como Incremento de Producto es la suma de todos los ítems del Product Backlog (PBIs) completados durante un Sprint y el valor de los incrementos de todos los Sprints pasados. Es uno de los 3 artefactos de Scrum y se presenta en cada Sprint Review.

El compromiso del Increment: El Definition of Done

Como todos los artefactos en Scrum, el Increment también contienen un compromiso asociado. El compromiso del Increment es el Definition of Done.

¿Qué es el Definition of Done?

El Definition of Done «DoD» (o “Definición de terminado” en español) es una descripción formal del estado del Increment cuando cumple con las medidas de calidad requeridas para el producto.

Podemos decir que es un acuerdo común que nos sirve para determinar cuándo un elemento de la lista del producto está finalizado. Si un elemento del Product Backlog no cumple con la Definition of Done, no se puede publicar ni presentar en la Sprint Review. En su lugar, vuelve al Product Backlog para su consideración futura.

¿Quién crea el Definition of Done?

Si el Definition of Done para un Increment es parte de los estándares de la organización, todos los Scrum Teams deben seguirla como mínimo. Si no es un estándar organizacional, el Scrum Team debe crear un Definition of Done apropiada para el producto.

¿Qué pasa con el Definition of Done cuando hay múltiples equipos?

Cuando hay varios Equipos Scrum trabajando sobre un mismo producto, deberán establecer un único Definition of Done y cumplirlo en conjunto.

Ejemplo de Definition of Done

Podemos decir que el Definition of Done más básico de cualquier equipo es el siguiente:

  1. Cumple todos los Criterios de Aceptación.

A medida que el equipo desea aumentar la calidad de entrega de su producto puede agregar más ítems al Definition of Done.

Por ejemplo, en un contexto de desarrollo de software, un equipo podría agregar los siguientes ítems:

  1. Cumple todos los Criterios de Aceptación.
  2. El código cumple los estándares de sintaxis establecidos.
  3. La solución fue implementada con Test-Driven Development (TDD).
  4. El código tiene 100% de cobertura de test unitarios.

En cambio, en un contexto de servicios un equipo podría agregar los siguientes ítems:

  1. Cumple todos los Criterios de Aceptación.
  2. Todas las tareas de la User Story fueron completadas
  3. Todo el trabajo y documentación requerida está adjuntado en la User Story para que el Product Owner pueda revisarlo.

¿Cuál es la diferencia entre el Definition of Done y los Criterio de Aceptación?

Mientras que los Criterios de Aceptación son condiciones particulares de cada elemento del Product Backlog, el Definition of Done son condiciones que se deben cumplir en todos los elementos del Product Backlog.

¿Se puede tener más de un Definition of Done?

Si bien en la mayoría de los casos tenemos un único Definition of Done que se aplica a todos los elementos del Product Backlog podríamos identificar elementos que requieran tener su propia definición. Por ejemplo podríamos tener un DoD general, que se aplique a todos los elementos del Product Backlog y otro DoD adicional que se aplique solamente a los requerimientos de documentación legal o que requieran diseño gráfico.

El Increment en Scrum y el empirismo

Hay veces que puede ser complicado comprobar si el equipo ha creado valor en cada Sprint. No obstante, el Product Owner quiere asegurarse de que el producto aumente su valor en cada Sprint.

El Product Owner desea crear un producto valioso de la forma más adecuada. El mercado tiene distintas necesidades y siempre existe la posibilidad de un desequilibrio entre ellas y los objetivos del Product Owner. Por lo tanto, el Product Owner debe corroborar regularmente que las cosas que se desarrollaron estén en buen camino para crear el valor que imaginó.

Haciendo uso de Scrum como marco de trabajo empírico, debemos buscar que nuestro Incremento nos permita obtener información nueva y relevante sobre el mercado y el contexto para poder adaptarnos rápidamente. Es por esto que debemos prestar atención al momento de inspeccionar este artefacto, qué hipótesis de negocio estamos validando y qué aprendimos del producto.

Equipos multidisciplinarios y multifuncionales

Las partes interesadas esperan que los Developers entregue algo concreto al finalizar cada Sprint, algo que les aporte valor a ellos. Un de especialistas de varios silos organizativos, o incluso varios equipos de desarrollo que trabajan juntos, puede creer que tienen un producto real cuando estos especialistas completan su trabajo. Pero, debido a la falta de una perspectiva de equipo compartida, es posible que no hayan producido nada más que componentes aislados. Todo el producto es más valioso que la suma de estos componentes, y el valor real proviene de la integración de estos componentes en un todo coherente. Es improbable que al mercado le importe cómo el equipo particionó el producto para su conveniencia de desarrollo.

Para entregar el Incremento, los Developers debe ser multifuncional, es decir, que cuente con todas las habilidades necesarias para entregar un incremento de valor al finalizar cada Sprint.
Desde mi punto de vista creo que este es uno de los mayores desafíos que vengo observando en distintas organizaciones que intentan adoptar Scrum, dado que suelen existir incentivos hacia las personas y equipos en especializarse en un área o tecnología lo cual dificulta que un equipo solo pueda crear un Incremento completo.

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

Principio del Manifiesto Ágil

El incremento debe ser un paso hacia la visión del producto o algún objetivo que responde a esa visión. En este sentido es muy útil tener bien presente el Objetivo del Sprint a la hora de construir cada Incremento.

Conclusiones

En el momento en que un elemento del Product Backlog cumple con la Definición de Terminado, nace un Increment. La Definición de Terminado pretende crear transparencia al brindar a todos un entendimiento compartido de qué trabajo se completó como parte del Increment.

Y en tu producto ¿entregan un Increment en cada Sprint que cumpla con un Definition of Done? Te leo acá abajo.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Más sobre Reglas de Scrum | Scrum

El Product Owner

El Product Owner

¿Qué es un Product Owner? El Product Owner es el miembro del equipo Scrum responsable de maximizar el valor del producto entregado por el equipo. El objetivo del Product Owner es lograr que entreguemos el producto "correcto", el producto que quiere el mercado y...