La Definition of Done en Scrum

Definition of Done Scrum

Ya hablamos de la importancia de redactar la Definition of Ready durante el Sprint Cero. Vamos ahora con el otro documento que no debe faltar antes de comenzar con los desarrollos en un proyecto Scrum: la Definition of Done.

Debes tener muy clara la importancia de dejar definidas y por escrito este par de reglas tan importantes de cara al buen entendimiento del Equipo Scrum: la Definition of Ready y la Definition of Done.

No obstante, son prácticas recomendadas que no forman parte del core del framework. En la Guía Scrum, de hecho, ni siquiera te hace referencia a la DoR. Pero que esto no te sirva como excusa para despreciarlas y no hacerlas. 

Qué es la Definition of Done (DoD)

Supongamos que estamos terminando con el Sprint y tenemos una determinada historia de usuario construida por el Equipo de Desarrollo. Puede ocurrir que lo que el Equipo de Desarrollo dé por hecho puede no coincidir con la idea que el Product Owner tenga en la cabeza de lo que supone tener una historia de usuario terminada.

Un Equipo Scrum sensato no debe dar lugar a situaciones de desacuerdo entre Product Owner y DevTeam, debe dejar muy bien definidos qué criterios determinan que una historia de usuario del Sprint Backlog está terminada. He aquí donde deberemos redactar, escribir y poner a la vista de todos la Definition of Done.

La DoD describe los criterios y actividades que debemos tener presentes para poder considerar que una historia de usuario está hecha o terminada antes de que acabe el Sprint.

Evidentemente, tanto la DoR como la DoD son una muestra más de la importancia que Scrum da a la transparencia. Y es que la transparencia es el mejor antídoto ante la ambigüedad y la falta de entendimiento.

Quién crea la Definition of Done

Veamos que dice la Guía Scrum:

Si la definición de “Terminado” para un incremento es parte de las convenciones, estándares o guías de la organización de desarrollo, al menos todos los Equipos Scrum deben seguirla.


Si “Terminado” para un incremento no es una convención de la organización de desarrollo, el Equipo de Desarrollo del Equipo Scrum debe especificar una definición de “Terminado” apropiada para el producto. Si hay múltiples Equipos Scrum trabajando en la entrega del sistema o producto, los Equipos de Desarrollo en todos los Equipos Scrum deben definir en conjunto la definición de “Terminado”.  

En resumen, podemos decir que el área de desarrollo de la organización debería ser la responsable, en principio, de crear la DoD, ya que estos criterios deberían ser comunes para todos los proyectos Scrum.

No obstante, en una gran mayoría de casos la organización no se mete en esas cuestiones (muy mal, por cierto), así que sería el DevTeam quien redactará la DoD en base a sus necesidades.

Personalmente discrepo. No considero que el DevTeam deba, unilateralmente, definir qué funcionalidad podemos dar por terminada o no. Debería llegarse a un consenso entre todos los miembros del Equipo Scrum ya que el Product Owner, como responsable principal del producto, no puede quedarse al margen de esta decisión.

¿Hay que actualizar la DoD? ¿cuándo?

Veamos qué dice la Guía:

A medida que los Equipos Scrum maduran, se espera que su definición de “Terminado” se amplíe para incluir criterios más rigurosos para una mayor calidad. El uso de las nuevas definiciones puede descubrir trabajo por hacer en los incrementos previamente “Terminados”. Cualquier producto o sistema debería tener una definición de “Terminado” que es un estándar para cualquier trabajo realizado sobre él.

Pues dicho queda. La DoD no está escrito en piedra, hay que mejorarlo con el tiempo, como pasa con todo en Scrum.

También dice la Guía:

Durante cada Retrospectiva de Sprint, el Equipo Scrum planifica formas de mejorar la calidad del producto mediante el mejoramiento de la calidad de los procesos o adaptando la Definición de “Terminado” (Definition of “Done”) según sea conveniente y no entre en conflicto con los estándares del producto u organizacionales.

Ya hablaremos del evento Retrospectiva cuando toque, pero quédate ahora con esta idea: en la Retro el Equipo Scrum al completo revisa la DoD y se mejora y readapta si procede y no colisiona con los estándares de la Organización.

Ejemplo de Definition of Done

Te dejo aquí un ejemplo de DoD para que lo reutilices y lo adaptes a tus circunstancias:

DoD – Proyecto XXX

  • El código debe estar escrito.
  • El código debe estar documentado o comentado.
  • El código se ha integrado en el servidor de CERTIFICACIÓN/PREPRODUCCIÓN.
  • El código compila.
  • Cumplimos con los criterios de aceptación de la historia de usuario.
  • El código funciona tras haber sido probado apropiadamente tanto en entorno de CERTIFICACIÓN como de PREPRODUCCIÓN. Las Historias de Usuario han pasado las pruebas (testing) manuales, automáticas, de rendimiento y regresivas, según los criterios de aceptación y los criterios de rendimiento.
  • Tenemos el OK del Product Owner y de los stakeholders en el Sprint Review.
  • La documentación está correctamente completada: creado documento de Diseño Técnico, Subidas evidencias a ALM, actualizado Confluence.
  • Antes de poner a Done la Historia de Usuario o Historia Técnica, deben estar Done todas sus sub-tareas y sus sub-bugs.
  • Historia resuelta y cerrada en el panel Scrum físico o en Jira (en estado Done).

¿Puedo tener más de una DoD?

Puedes rizar el rizo y crear más de una DoD si lo necesitas. Podrías escribir una DoD para las historias de usuario (qué criterios determinan que una historia de usuario está terminada), otra DoD para los Sprints (qué criterios determinan si en ese Sprint se cumplió el Sprint goal o no) e incluso otra DoD por Releases (qué criterios determinan que una release de software está hecha y por tanto lista para subirla a Producción).

Está última DoD por Release me resulta más interesante que por Sprint. No obstante, personalmente me parece innecesario tener varias DoD, pero ahí te dejo un ejemplo:

DoD por Historia – Proyecto XXX

  • El código debe estar escrito.
  • El código debe estar documentado o comentado.
  • El código se ha integrado en el servidor de CERTIFICACIÓN/PREPRODUCCIÓN.
  • El código compila.
  • Cumplimos con los criterios de aceptación de la historia de usuario.
  • El código funciona tras haber sido probado apropiadamente tanto en entorno de CERTIFICACIÓN como de PREPRODUCCIÓN. Las Historias de Usuario han pasado las pruebas (testing) manuales, automáticas, de rendimiento y regresivas según los criterios de aceptación y los criterios de rendimiento.
  • La documentación está correctamente completada: creado documento de Diseño Técnico, Subidas evidencias a ALM, actualizado Confluence.   
  • Incidencias detectadas en el Sprint, están resueltas.
  • Historia aprobada por el Product Owner y stakeholders.
  • Antes de poner a Done la Historia de Usuario o Historia Técnica, deben estar Done todas sus sub-tareas y sus sub-bugs.
  • Historia resuelta y cerrada en el panel Scrum físico o en Jira (en estado Done).

DoD por Sprint – Proyecto XXX

  • Se cumple el DoD por Historia para todas las Historias del Sprint.
  • Todas las historias acordadas durante en Sprint Planning están Done.
  • Demo verificada en la Review por parte de Product Owner y stakeholders. Hemos recibido el feedback correspondiente cumpliendo con los criterios de transparencia, inspección y adaptación.
  • OK del Product Owner al Sprint. Daríamos por cumplido el Sprint Goal.

DoD por Release – Proyecto XXX

  • Se cumple el Sprint Goal de los Sprints que liberaremos dentro de la Release en Producción. Es decir, cumplimos con el DoD por cada Sprint.
  • Pruebas de Carga (Performance) de la Release en PRE: OK del Equipo de Rendimiento.
  • Pruebas de Operaciones de la Release en PRE.
  • Documentación unificada de la Release subida a repositorio (Confluence).

Reflexión final

Lo mismo que dijimos respecto a la DoR, decimos ahora: la DoD no es un formalismo absurdo.

Como puedes observar en los ejemplos que te he puesto, hay cuestiones que a simple vista no son tan evidentes y que pueden ocasionar conflicto entre Product Owner y DevTeam. Sobre todo cuestiones técnicas (por ejemplo, cumplir con las pruebas regresivas, o documentar los casos de prueba en ALM, etc) que el Product Owner puede no darles la importancia que merecen.

Así que ahórrate desacuerdos y malos rollos y ten bien redactado y visible a todos este documento. El esfuerzo merecerá la pena con creces.

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

2 comentarios en “<b>La Definition of Done en Scrum</b>”

  1. Hola,
    Muy buen articulo, me queda una duda, si por ejemplo el equipo no cumplio por ejemplo la automatizacion de los test de algunos sprint anteriores y se dio cuanta recien y debe realizarse, eso es una Historia técnica o funcional para ingresar en el backlog del siguiente sprint?

    Le agradecería los comentarios.

    Responder
    • Buenas Kar, gracias por comentar. Ciertamente, yo reflejaría ese trabajo en el siguiente Sprint como una historia técnica. De hecho, en herramientas como Jira puedes ser incluso más preciso y reflejarlo como un ítem de deuda técnica, que al fin y al cabo es lo que sería, deuda técnica debido a algo que no completaste en Sprints previos.

      Un saludo.

      Responder

Deja un comentario