Definition of Done: Guia Completa con Ejemplos y Checklist

Por Abhay Talreja

28/12/2025

Mi último artículo - Empirical Process Control - The Key to Agile Success

La Definition of Done (DoD) es un compromiso formal en Scrum y Agile que establece los criterios de calidad que cada item del Product Backlog e Increment debe cumplir antes de considerarse completo. No es solo una checklist - es un entendimiento compartido entre todo el Scrum Team sobre lo que significa "done", creando transparencia y asegurando Increments potencialmente entregables.

Caracteristicas clave: La Definition of Done se aplica universalmente a TODO el trabajo (a diferencia de los Acceptance Criteria que varian por story), evoluciona a medida que maduran las capacidades del equipo, y es innegociable - el trabajo que no cumple con DoD no puede liberarse. Tipicamente incluye revision de codigo, pruebas automatizadas con umbrales de cobertura especificos, actualizaciones de documentacion, escaneos de seguridad y verificacion de despliegue.

Distincion critica: La Definition of Done define estandares de CALIDAD (ej., "codigo revisado," "tests >80% cobertura"), mientras que Acceptance Criteria define requisitos FUNCIONALES (ej., "el usuario puede iniciar sesion con email"). Ambos deben cumplirse para que el trabajo este realmente Done.

Respuesta Rapida: Definition of Done de un Vistazo

Lo Que Aprenderas en Esta Guia

En esta guia completa, descubriras:

• Los Fundamentos: Que significa realmente Definition of Done en Scrum y por que es un compromiso, no solo una checklist
• DoD vs Acceptance Criteria: Distinciones claras con comparaciones lado a lado y ejemplos practicos mostrando como ambos deben cumplirse
• Checklists Especificos por Industria: Ejemplos de DoD listos para usar para 6 industrias (SaaS, Salud, Finanzas, E-commerce, Movil, DevOps)
• La Jerarquia de Tres Niveles: Como estructurar DoD a nivel de Feature, Sprint y Release con marcos de decision
• Viaje de Madurez: Fortalecimiento progresivo desde DoD Basica (equipos nuevos) hasta Intermedia y Avanzada (equipos de alto rendimiento)
• Errores Comunes: 8 anti-patrones criticos que los equipos cometen con DoD y exactamente como corregirlos
• Estrategia de Evolucion: Guia paso a paso para mejorar incrementalmente DoD sin abrumar al equipo
• Implementacion Practica: Proceso de creacion colaborativa, estrategias de visibilidad y tecnicas de aplicacion

Por Que la Definition of Done Importa Hoy

La Definition of Done no es solo otra formalidad de Scrum - es el guardian de calidad que previene la acumulacion de deuda tecnica y asegura que cada Sprint entregue Increments potencialmente entregables. Este compromiso critico permite a los equipos:

• Eliminar la ambiguedad de calidad a traves de estandares explicitos y medibles que todos entienden
• Prevenir la expansion del alcance definiendo claramente cuando el trabajo esta completo vs. cuando aun esta en progreso
• Habilitar releases predecibles porque "done" significa genuinamente liberable, no "casi done"
• Apoyar equipos distribuidos con verificacion automatizada reduciendo las necesidades de comunicacion sincrona
• Escalar consistentemente entre multiples equipos trabajando en el mismo producto con estandares compartidos

Ya sea que estes estableciendo DoD para un nuevo equipo Scrum, fortaleciendo DoD para un equipo en maduracion, o asegurando cumplimiento en industrias reguladas (salud, finanzas, gobierno), esta guia proporciona marcos probados para el exito.

Exploremos como crear, implementar y evolucionar una Definition of Done que transforme las capacidades de calidad y entrega de tu equipo.

Que es Doneness?

En Scrum, "doneness" se refiere al estado de completitud de un Product Backlog Item (PBI) o un Increment.

Indica que el trabajo ha sido terminado a un nivel de calidad y completitud que es aceptable para el Scrum Team y los stakeholders.

Para asegurar un entendimiento compartido de cuando un PBI o Increment se considera completo, los Scrum Teams usan la Definition of Done.

Definition of Done

La Definition of Done (DoD) es un entendimiento compartido entre los miembros del Scrum Team de los criterios que deben cumplirse para que un PBI o Increment se considere completo.

Establece un conjunto claro y consistente de expectativas, asegurando que todos en el equipo sepan que se requiere para terminar una tarea exitosamente.

Mientras las especificidades pueden variar de una organizacion a otra, una DoD tipica abarca items clave como:

• El codigo esta peer-reviewed: Asegurando que el codigo sea examinado por pares para calidad y precision.
• El codigo esta checked in: Haciendo commit del codigo al control de versiones para acceso del equipo.
• El codigo esta desplegado en un ambiente de prueba: Haciendo el codigo disponible para testing.
• El codigo/feature pasa regression testing: Verificando que los cambios no rompen funcionalidad existente.
• El codigo/feature pasa smoke testing: Realizando pruebas basicas para asegurar que el feature funciona como se pretende.
• El codigo esta documentado: Creando documentacion completa para ayudar a la comprension y mantenimiento futuro.
• La documentacion de ayuda esta actualizada: Asegurando que la documentacion orientada al usuario sea precisa y completa.
• El feature esta aprobado por stakeholders: Obteniendo aprobacion de stakeholders relevantes para la preparacion del feature.

Estos checkpoints colectivamente sirven como guardian, distinguiendo entre trabajo "en progreso" y el que esta genuinamente "done."

Actuan como una red de seguridad para mantener calidad y completitud a lo largo del proceso de desarrollo.

La Guia Scrum Descifrada

Segun la Guia Scrum, la Definition of Done sirve como un blueprint formal del estado que un Increment debe alcanzar para cumplir con los estandares de calidad requeridos para el producto.

Una vez que se cumplen los criterios de la Definition of Done, el Increment gana el codiciado estado de "Done" y esta listo para entrega.

Los Objetivos de la Definition of Done

Construyendo Consenso sobre Calidad

Uno de los objetivos principales de DoD es fomentar un entendimiento comun dentro del equipo sobre calidad y completitud.

Cuando todos estan de acuerdo en lo que significa 'done', elimina confusion y agiliza el proceso de desarrollo.

Una Checklist Confiable

DoD actua como una checklist confiable contra la cual se verifican las User Stories o Product Backlog Items.

Esto asegura que nada se escape, y cada aspecto de una tarea sea examinado meticulosamente.

Asegurando Increments de Alta Calidad

En ultima instancia, el objetivo primordial de DoD es asegurar que el increment enviado al final del Sprint sea de alta calidad.

Esta calidad debe ser claramente entendida por todos los miembros del equipo, stakeholders y cualquier persona involucrada en el proyecto.

Beneficios de la Definition of Done

Tener una Definition of Done bien definida es esencial en el desarrollo Agile por varias razones:

• Proporciona claridad y consistencia: Los miembros del equipo y stakeholders tienen un claro entendimiento de lo que se espera para cada tarea completada.
• Mejora la calidad: Al definir estandares de calidad y requisitos de testing, ayuda a entregar un producto de mayor calidad.
• Reduce malentendidos: Minimiza el riesgo de mala comunicacion y asegura que todos esten en la misma pagina respecto a la completitud del proyecto.
• Ayuda en la toma de decisiones: Ayuda al equipo a decidir cuando una tarea o feature esta lista para release, agilizando el proceso de desarrollo.
• Mejora la transparencia: Los stakeholders pueden rastrear el progreso mas efectivamente, sabiendo que "done" significa que todo el trabajo necesario esta completo.

Por Donde Comenzar el Proceso de Definicion

Definir la DoD debe ser un esfuerzo colaborativo que involucre a stakeholders y aquellos responsables del trabajo real.

Ya sea que comience con brainstorming o un marco propuesto por el equipo tecnico, amplias oportunidades para retroalimentacion y apoyo unanime para la DoD final son esenciales.

Asignar propiedad a cada criterio ayuda a resolver disputas y mantener consistencia.

En adherencia al principio Agile de simplicidad, la DoD debe ser concisa. Su proposito es asegurar calidad consistente, no crear obstaculos burocraticos.

Complicar demasiado la DoD puede impedir el progreso en lugar de facilitarlo.

Creando una Definition of Done Efectiva

Para crear una Definition of Done efectiva para tu Scrum Team, sigue estos pasos:

1. Colaborar: Involucra a todo el Scrum Team en la creacion de la DoD, asegurando que se considere la perspectiva de todos, y se establezca un entendimiento compartido.

2. Definir Criterios: Identifica los criterios que deben cumplirse para que un PBI o Increment se considere completo. Incluye aspectos como funcionalidad, calidad, rendimiento, documentacion y cumplimiento.

3. Mantenerla Visible: Haz la DoD facilmente accesible y visible para todo el Scrum Team, asegurando que los miembros del equipo siempre esten conscientes de las expectativas.

4. Revisar y Actualizar: Revisa y actualiza regularmente la DoD basandote en los aprendizajes, experiencias y requisitos cambiantes del Scrum Team.

Tres Preguntas Criticas

Para determinar donde pertenece una actividad en la jerarquia de DoD, tres preguntas deben guiar tu proceso de toma de decisiones:

• Podemos hacer esta actividad para cada feature?
• Si no, podemos hacer esta actividad para cada sprint?
• Si no, se vuelve imperativo incluir esta actividad para nuestro release.

Definition of Done vs Acceptance Criteria: Diferencias Clave

Muchos equipos confunden Definition of Done con Acceptance Criteria - pero sirven propositos diferentes y deben trabajar juntas.

Definition of Done (DoD)

Alcance: Se aplica a TODO el trabajo en TODOS los Product Backlog items

Proposito: Define estandares de calidad y practicas tecnicas

Quien la Define: Scrum Team colaborativamente (a menudo heredada de estandares organizacionales)

Ejemplos de Items de DoD:

• Codigo revisado por al menos un par
• Unit tests escritos y pasando (>80% cobertura)
• Integration tests pasando
• Sin bugs criticos o de alta prioridad
• Documentacion actualizada
• Escaneo de seguridad completado
• Benchmarks de rendimiento cumplidos

Punto Clave: DoD es consistente entre todos los features - cada item debe cumplir la misma barra de calidad.

Acceptance Criteria (AC)

Alcance: Unico para cada Product Backlog item o user story especifico

Proposito: Define requisitos funcionales y logica de negocio

Quien la Define: Product Owner (con input de Developers sobre viabilidad)

Ejemplo de AC para Story "Login de Usuario":

• Usuario puede iniciar sesion con email y contrasena
• Credenciales invalidas muestran mensaje de error
• Login exitoso redirige al dashboard
• Link "Olvide contrasena" envia email de reset
• Login persiste 30 dias con "Recordarme"

Punto Clave: AC varia por story - cada feature tiene requisitos funcionales unicos.

Trabajando Juntas

Ambas deben cumplirse: El trabajo solo esta "Done" cuando cumple tanto la Definition of Done (calidad) como los Acceptance Criteria (funcionalidad).

Ejemplos de Definition of Done por Industria

Diferentes industrias requieren diferentes items de DoD basados en cumplimiento, seguridad y requisitos especificos del dominio.

Software-as-a-Service (SaaS)

✓ Codigo revisado y aprobado
✓ Unit tests pasando (minimo 80% cobertura)
✓ Integration tests pasando
✓ Documentacion de API actualizada
✓ Escaneo de vulnerabilidades de seguridad pasado
✓ Performance testing completado (< 2s tiempo de respuesta)
✓ Feature flag configurado
✓ Monitoreo y alertas configurados
✓ Runbook de despliegue actualizado
✓ Product Owner aprobo

Salud / Software Compatible con HIPAA

✓ Codigo revisado por developer senior
✓ Todos los tests pasando (unit, integration, E2E)
✓ Checklist de cumplimiento HIPAA completado
✓ Encriptacion de datos PHI verificada
✓ Audit logging implementado
✓ Controles de acceso probados
✓ Revision de seguridad pasada
✓ Evaluacion de impacto de privacidad completada
✓ Documentacion actualizada (tecnica + usuario)
✓ Oficial de cumplimiento aprobo

Servicios Financieros / Banca

✓ Codigo revisado (revision dual para rutas criticas)
✓ Tests automatizados pasando (>90% cobertura)
✓ Cumplimiento PCI-DSS verificado
✓ Penetration testing completado
✓ Tests de integridad de transacciones pasados
✓ Procedimiento de rollback documentado
✓ Reglas de deteccion de fraude actualizadas
✓ Capacidad de reporte regulatorio verificada
✓ Audit trail implementado
✓ Change Advisory Board aprobo

Plataforma E-Commerce

✓ Codigo peer-reviewed
✓ Unit + integration tests pasando
✓ Cross-browser testing completado (Chrome, Safari, Firefox, Edge)
✓ Diseno responsive movil verificado
✓ Tiempo de carga de pagina < 3 segundos
✓ Analytics tracking implementado
✓ SEO meta tags agregados
✓ Flujo de carrito y checkout probado
✓ Integracion de payment gateway probada
✓ User acceptance testing pasado

Desarrollo de Apps Moviles

✓ Codigo revisado
✓ Unit tests pasando (>75% cobertura)
✓ UI/UX coincide con specs de diseno
✓ Probado en iOS (ultima + 2 versiones anteriores)
✓ Probado en Android (ultima + 3 versiones anteriores)
✓ Estandares de accesibilidad cumplidos (WCAG 2.1 AA)
✓ Screenshots y descripciones de app store listos
✓ Crash reporting configurado
✓ Analytics events rastreando correctamente
✓ Privacy policy y permisos actualizados

DevOps / Infraestructura

✓ Infrastructure as Code (IaC) peer-reviewed
✓ Tests automatizados pasando
✓ Security groups y IAM policies revisadas
✓ Estimacion de costos completada
✓ Dashboards de monitoreo creados
✓ Alertas y runbooks documentados
✓ Disaster recovery probado
✓ Ticket de change management aprobado
✓ Despliegue verificado en staging
✓ Procedimiento de rollback documentado y probado

Los Tres Niveles de Definition of Done

Segun Scrum Alliance y expertos Agile, DoD puede existir en multiples niveles - los equipos deben decidir conscientemente donde pertenece cada actividad de calidad.

Nivel 1: DoD a Nivel de Feature

Actividades realizadas para CADA Product Backlog item

✓ Codigo escrito siguiendo estandares de codificacion ✓ Unit tests escritos y pasando ✓ Codigo peer-reviewed ✓ Acceptance Criteria cumplidos ✓ Testing local completado

Pregunta: Podemos realisticamente hacer esto para cada feature individual?

Nivel 2: DoD a Nivel de Sprint

Actividades realizadas una vez por Sprint para el Increment completo

✓ Integration testing entre todos los features del Sprint ✓ Suite de regression testing ejecutada ✓ Performance testing completado ✓ Security scan ejecutado ✓ Documentacion del Sprint consolidada ✓ Increment desplegado a ambiente de staging

Pregunta: Si no es factible por feature, podemos hacerlo una vez por Sprint?

Nivel 3: DoD a Nivel de Release

Actividades realizadas antes de liberar a produccion

✓ User acceptance testing (UAT) con stakeholders ✓ Load testing bajo condiciones similares a produccion ✓ Penetration testing y auditoria de seguridad ✓ Revision de cumplimiento y sign-off ✓ Runbook de despliegue a produccion ejecutado ✓ Materiales de marketing y release notes preparados ✓ Soporte al cliente entrenado en nuevos features

Pregunta: Si no es factible por Sprint, debemos hacerlo antes del release?

Por Que Importan Multiples Niveles

Realidad: No todas las actividades de calidad pueden hacerse para cada feature. Ejemplos:

• Full penetration testing no puede suceder para cada story - es una actividad de nivel Release
• Integration testing entre todos los features sucede una vez por Sprint, no por feature
• Load testing con 10,000 usuarios concurrentes es prohibitivamente caro por feature

Solucion: Se explicito sobre a que nivel pertenece cada actividad de DoD. Esto crea:

• Transparencia: Todos saben cuando suceden las actividades
• Expectativas realistas: Los equipos no prometen actividades imposibles por feature
• Quality gates: Las actividades criticas no se saltan - se programan apropiadamente

Errores Comunes de Definition of Done (Y Como Corregirlos)

Error 1: Confundir DoD con Acceptance Criteria

Problema: El equipo trata DoD como requisitos funcionales en lugar de estandares de calidad

Ejemplo: DoD incluye "Usuario puede iniciar sesion con email" (esto es Acceptance Criteria)

Correccion: DoD debe ser estandares tecnicos/de calidad (ej., "Todos los features orientados al usuario tienen >80% cobertura de tests"), no especificaciones funcionales

Error 2: Crear una DoD Imposible

Problema: DoD incluye actividades que el equipo realmente no puede completar cada Sprint

Ejemplo: "Auditoria de seguridad completa por firma externa" (cuesta $50K, toma 3 semanas)

Correccion: Mover esto a DoD de nivel Release. DoD de Sprint podria ser "Escaneo de seguridad automatizado pasado"

Error 3: DoD Demasiado Vaga

Problema: Declaraciones genericas que no impulsan accion

Ejemplo: "El codigo debe ser de alta calidad" o "Testing completo"

Correccion: Se especifico: "Codigo revisado por developer senior" y "Unit tests >80% cobertura, integration tests pasando, smoke tests pasados"

Error 4: Nunca Evolucionar la DoD

Problema: El equipo usa la misma DoD por anos a pesar de ganar capacidades

Ejemplo: El equipo aprende automated testing pero DoD aun dice "Solo testing manual"

Correccion: Revisar DoD trimestralmente en Retrospectives. A medida que el equipo mejora, fortalecer DoD (ej., subir cobertura de tests de 70% → 80% → 90%)

Error 5: Saltarse DoD Cuando "Bajo Presion"

Problema: El equipo compromete DoD para cumplir Sprint Goal, acumulando deuda tecnica

Ejemplo: "Saltaremos code review esta vez - estamos atrasados"

Correccion: DoD es innegociable. Si no puedes cumplir DoD, el trabajo NO esta Done. Reduce alcance en lugar de comprometer calidad

Error 6: Una Persona Posee DoD

Problema: Solo el Scrum Master o tech lead define DoD sin input del equipo

Ejemplo: Tech lead crea checklist de 20 items de DoD sin consultar a Developers

Correccion: Todo el Scrum Team colabora en DoD. Todos deben entenderla y comprometerse con ella

Error 7: No Mostrar DoD Visiblemente

Problema: DoD vive en una wiki que nadie revisa

Ejemplo: "Donde esta nuestra DoD?" "Uh... en algun lugar en Confluence?"

Correccion: Hacer DoD visible en tu board, en Sprint Planning, y durante Sprint Review

Error 8: DoD Sin Propiedad

Problema: Items de DoD existen pero nadie verifica cumplimiento

Ejemplo: DoD dice "Documentacion actualizada" pero nadie verifica si sucedio

Correccion: Asignar propiedad clara para verificacion de cada item de DoD, o hacerlo parte del checklist de code review

Como Evoluciona la Definition of Done: El Viaje de Madurez

Los grandes equipos no comienzan con DoD perfecta - la fortalecen con el tiempo a medida que mejoran las capacidades.

Etapa 1: DoD Basica (Nuevos Scrum Teams)

DoD Tipica:

✓ Codigo escrito
✓ Codigo committed a control de versiones
✓ Testing manual basico completado
✓ Acceptance Criteria cumplidos

Caracteristicas:

• Minimo automated testing
• Alta dependencia de testing manual
• Verificaciones de calidad basicas
• Enfoque en hacer el trabajo "funcional"

Enfoque de Mejora: Introducir automated unit testing y peer review

Etapa 2: DoD Intermedia (Equipos en Maduracion)

DoD Tipica:

✓ Codigo revisado por par
✓ Unit tests escritos (>60% cobertura)
✓ Integration tests pasando
✓ Acceptance Criteria cumplidos
✓ Desplegado a ambiente de test
✓ Documentacion basica actualizada

Caracteristicas:

• Automated testing emergiendo
• Proceso de code review establecido
• Pipeline CI/CD comenzando
• Calidad volviendose sistematica

Enfoque de Mejora: Aumentar cobertura de tests, agregar automated deployment

Etapa 3: DoD Avanzada (Equipos de Alto Rendimiento)

DoD Tipica:

✓ Codigo revisado y aprobado
✓ Unit tests pasando (>85% cobertura)
✓ Integration tests pasando
✓ E2E tests pasando
✓ Security scan pasado
✓ Benchmarks de rendimiento cumplidos (<2s respuesta)
✓ Estandares de accesibilidad verificados (WCAG 2.1 AA)
✓ Documentacion actualizada (codigo + usuario)
✓ Feature flag configurado
✓ Monitoreo/alertas configurados
✓ Desplegado automaticamente a staging
✓ Product Owner aprobo en staging

Caracteristicas:

• Automated testing comprehensivo
• Pipeline CI/CD completo
• Medidas de calidad proactivas
• "Potencialmente entregable" realmente significa entregable

Enfoque de Mejora: Mejora continua a traves de metricas y feedback

Como Fortalecer Tu DoD

Paso 1: Identificar Brechas Actuales

Durante Sprint Retrospective, preguntar:

• Que problemas de calidad se escaparon a pesar de cumplir DoD?
• Que deuda tecnica estamos acumulando?
• Que causa retrabajo o bugs en produccion?

Paso 2: Agregar Una Mejora a la Vez

No abrumar al equipo. Fortalecer DoD incrementalmente:

• Sprint 1-3: Agregar requisito de peer code review
• Sprint 4-6: Requerir unit tests para codigo nuevo (>50% cobertura)
• Sprint 7-9: Aumentar a >70% cobertura
• Sprint 10+: Agregar requisito de integration testing

Paso 3: Invertir en Construccion de Capacidades

DoD solo puede mejorar si las capacidades del equipo mejoran:

• Necesitas mayor cobertura de tests? Proporcionar entrenamiento en TDD
• Necesitas mejor seguridad? Traer experto en seguridad para workshops
• Necesitas automated deployment? Invertir en infraestructura CI/CD

Paso 4: Medir y Adaptar

Rastrear metricas para validar mejoras de DoD:

• Tasa de defectos escapados (bugs encontrados en produccion)
• Tiempo para arreglar problemas de produccion
• Frecuencia de despliegue
• Tiempo medio de recuperacion (MTTR)

Conclusion

La Definition of Done es crucial para mantener transparencia, alinear expectativas de los miembros del equipo, y entregar un increment potencialmente liberable al final de cada sprint.

Va mas alla de la funcionalidad para afirmar la calidad de un feature. Informada por la realidad, se adapta a varios niveles, proporcionando claridad, y fomentando comunicacion dentro del equipo y con stakeholders.

Ayuda a prevenir que trabajo incompleto o de baja calidad se considere "done" y proporciona una guia clara de cuando el trabajo de desarrollo esta verdaderamente completo.

Entender la DoD y aplicarla efectivamente es un viaje hacia entregar no solo software sino excelencia en cada linea de codigo.

Al embarcarte en este viaje, recuerda que la Definition of Done es una herramienta dinamica, siempre lista para evolucionar y guiar a tu equipo hacia mayores alturas.

Continuar Leyendo

Preguntas Frecuentes (FAQs)