Definición de [Hecho] (Definition of Done - DoD)

La Definición de "Hecho" (Definition of Done - DoD) es otro acuerdo crucial y compartido dentro de un equipo ágil.

Actúa como una lista de verificación (checklist) que establece los criterios que debe cumplir un ítem del backlog (como una Historia de Usuario) o un Incremento de producto para ser considerado completamente terminado.

A diferencia de los Criterios de Aceptación (específicos de cada historia), la DoD es un estándar unificado que se aplica a todo el trabajo realizado por el equipo.

Su propósito es crear una comprensión compartida y transparente sobre la calidad y la completitud esperadas, evitando ambigüedades y el problema del trabajo "casi hecho".

Asegurando la Calidad y Completitud del Incremento

El principal objetivo de la DoD es garantizar la calidad y asegurar que cuando el equipo declara algo como "Hecho", realmente lo está, sin dejar trabajo pendiente oculto.

Ayuda a evitar situaciones en las que una funcionalidad se considera terminada desde la perspectiva de la codificación, pero aún faltan pasos importantes como pruebas exhaustivas, revisiones de código, actualización de documentación o limpieza del código.

La DoD define todas las actividades necesarias para que un incremento de producto sea potencialmente entregable y de alta calidad, asegurando que no se acumule deuda técnica innecesaria y que el trabajo cumpla con los estándares acordados por el equipo.

Creación Colaborativa de la Lista de Verificación DoD

Al igual que la Definición de "Listo", la DoD no es impuesta, sino que debe ser creada y acordada colaborativamente por todo el equipo Scrum (o equipo ágil).

Se define a través de una discusión donde el equipo establece sus propios estándares de calidad y completitud.

Esta lista de verificación es única para cada equipo y su contexto.

Elementos comunes que suelen incluirse en una DoD son:

• Código completado.
• Revisiones de código realizadas.
• Pruebas unitarias escritas y superadas (a menudo con un % de cobertura mínimo).
• Pruebas de integración realizadas.
• Pruebas de regresión superadas.
• Pruebas de automatización actualizadas (con un % de cobertura).
• Documentación necesaria actualizada.
• Aceptación por parte del Propietario de producto.
• Revisión y aceptación por parte del diseñador UX (si aplica).

La lista debe ser clara, pero no excesivamente compleja para no volverse burocrática. Puede ser una lista física o un entendimiento compartido.

DoD y su Impacto en la Estimación

Una DoD clara y compartida tiene un impacto directo y positivo en la estimación del trabajo.

Cuando el equipo estima una Historia de Usuario (ej., usando puntos de historia), no solo debe considerar el esfuerzo de codificación, sino todo el trabajo necesario para cumplir con la DoD.

Esto incluye el tiempo para pruebas, documentación, revisiones, etc.

Sin una DoD clara, la