¿Sabes cuál es la diferencia entre los artefactos principales y complementarios en Scrum?
Primero iniciemos por lo básico: ¿Qué es un Artefacto en Scrum?
Según la última actualización de la Guía Scrum 2020, los artefactos son instrumentos que permiten maximizar la transparencia y brindar al "Scrum Team" oportunidades de inspeccionar y adaptar el valor que entregan y cómo se entregan.
De acuerdo a la pregunta que encabeza este artículo los artefactos principales que se utilizan en Scrum son: Product Backlog, Sprint Backlog e Incremento; no obstante, me centraré en algunos artefactos complementarios, en específico 2: DoR y DoD.
La guía Scrum original ya era liviana y muy interpretable. Con los últimos cambios introducidos, creo que se tenía una buena intención de eliminar términos redundantes para "sumar mayor precisión y simplicidad", pero sin duda una guía más escueta aún, generará más interpretaciones todavía con el riesgo de implementaciones inadecuadas.
Desapareció el concepto DoR (Definición de Listo), para gustos y disgustos de muchos.
DoR (Definition of Ready)
Se puede explicar con una sencilla pregunta ¿Qué debería estar listo antes de aceptar Historias de Usuario (H.U.) en el siguiente Sprint? Utilizar DoR nos puede ayudar a incrementar la calidad de los requerimientos, reduciendo deuda técnica asociada a la documentación e incrementando el grado de eficacia de construcción de las Historias de Usuario y mayor entendimiento hacia los demás roles.
Si bien es cierto que el Product Owner debería absorber la responsabilidad de cumplirlo, el DoR puede ser construido de común acuerdo por todos los roles y puede materializarse en un CheckList visible si estamos trabajando presencialmente, o bien dentro de tus espacios virtuales colaborativos si se está trabajando de manera remota.
Como es sabido, la teoría muchas veces se queda corta en explicaciones y la nueva Guía no es la excepción, ya que tampoco prescribe formatos o formas para llevar la teoría a la realidad organizacional, debido a esto, las implementaciones varían bastante, por eso compartiré ejemplos para que te puedan ser de ayuda en tus implementaciones ágiles.
DoR que utilizo personalmente en mis implementaciones
La invitación es a tomar las variables de las listas anteriores y adaptes tu propio DoR según el contexto de tu organización. Si bien es cierto que este artefacto desapareció en la última guía, puedes seguir utilizando este artefacto complementario para incrementar calidad en tu producto o servicio. Que no esté en la guía no quiere decir que es la verdad absoluta.
El segundo artefacto complementario que detallaré es DoD.
DoD (Definition of Done)
Es una descripción formal del estado del Incremento cuando cumple con las medidas de calidad requeridas para el producto.
En la nueva guía este artefacto complementario recibe mayor importancia y es tratado como "un compromiso".
De manera textual: "La Definición de Terminado está orientado a crear transparencia al brindar a todos un entendimiento compartido de qué trabajo se completó como parte del Incremento. Si un elemento del Product Backlog no cumple con la Definición de Terminado, no se puede publicar ni presentar en la Sprint Review. En su lugar, vuelve al Product Backlog para su consideración futura. Si la Definición de Terminado para un Incremento 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 una Definición de Terminado apropiada para el producto".
Si bien es cierto que Developers absorben la responsabilidad del incremento, el DoD puede ser construido de común acuerdo por todos los roles y puede materializarse en un CheckList visible, con el mismo tratamiento que un DoR.
Al igual que el DoD, DoR se puede explicar con una sencilla pregunta ¿Qué debe cumplir una Historia de Usuario para que esté terminada (usable)? Utilizar DoD nos puede ayudar a incrementar la calidad de los productos o servicios, reduciendo deuda técnica asociada a los entregables e incrementando el grado de valor entregado hacia los usuarios finales como también hacia Stakeholders.
Nuevamente compartiré ejemplos de DoD que utilizo en mis implementaciones
No existe una única receta para DoR y DoD, ya que como mencioné anteriormente dependerá del contexto de la organización, del nivel de madurez de los roles y el tipo de cultura predominante.
Lo importante a tener en cuenta es que si te ayudan a incrementar la calidad de tu producto o servicio y tu usuario final está feliz y conforme, entonces son buenos indicios.