Definition of Done (DoD): El Pequeño Detalle que Separa Proyectos Caóticos de Proyectos Exitosos
¿Alguna vez tu equipo entregó lo que creía que era «listo» y luego descubriste que faltaban pruebas, documentación o que el código ni siquiera compilaba?
¿Cuántas veces escuchaste «bueno, técnicamente está Done» cuando claramente no lo estaba?
La Definition of Done (DoD) es la línea que define exactamente cuándo una tarea, historia o entregable está realmente terminado. No es una opinión, no es un «más o menos»—es un estándar cristalino que tu equipo decide al inicio y que todos siguen sin excepciones.
Sin DoD, cada miembro de tu equipo tiene su propia idea de qué significa «listo». Con DoD, todos van en la misma dirección.
¿Qué es Definition of Done y por qué es tan crítica?
La Definition of Done es una lista consensuada de criterios que un elemento de trabajo debe cumplir antes de marcarse como completado. Es tu checklist de calidad que evita que trabajo incompleto llegue al siguiente paso.
Estos 5 beneficios cambiarán cómo tu equipo trabaja:
- Elimina la ambigüedad: No hay «yo creía que estaba listo».
- Reduce defectos: Problemas se detectan temprano, no después de entregar al cliente.
- Acelera sprints: El equipo sabe exactamente qué hacer, sin sorpresas de último minuto.
- Mejora la confianza: Cliente y dirección saben que «listo» significa realmente listo.
- Onboarding más rápido: Nuevos miembros aprenden los estándares desde el día uno.
Las 3 capas de una Definition of Done efectiva
Capa 1: Criterios de Aceptación (Lo Técnico)
✅ Lo que el desarrollo debe cumplir:
- Código escrito y revisado por otro miembro del equipo.
- Pruebas unitarias con cobertura mínima del 80%.
- Sin errores críticos o warnings en el análisis estático.
- Integrado a la rama principal (merge a main/master).
- Documentación de código actualizada.
Capa 1: Criterios de Aceptación (Lo Técnico)
✅ Lo que el desarrollo debe cumplir:
- Código escrito y revisado por otro miembro del equipo.
- Pruebas unitarias con cobertura mínima del 80%.
- Sin errores críticos o warnings en el análisis estático.
- Integrado a la rama principal (merge a main/master).
- Documentación de código actualizada.
Capa 2: Criterios de Calidad (Lo Funcional)
✅ .Lo que el producto final debe lograr:
- Funcionalidad probada manualmente en ambiente de desarrollo.
- Se ejecuta sin errores en al menos dos navegadores (si es web).
- El comportamiento coincide exactamente con los requerimientos.
- Sin datos sensibles en logs o consola.
- Performance aceptable (tiempos de carga, memoria, etc.).
Capa 3: Criterios de Entrega (Lo Administrativo)
✅ .Lo que cierra el ciclo:
- Historia o tarea vinculada a un código commit específico.
- Actualizado en la herramienta de seguimiento (Jira, Azure DevOps, etc.).
- Comunicado al Product Owner o stakeholder.
- Listo para demostración en la reunión de cierre de sprint.
Cómo crear tu Definition of Done en 5 pasos
- 1. Reúne al equipo (toda la tribu: desarrollo, QA, producto). No puedes definir DoD sin los que lo van a usar. Necesitas perspectivas múltiples.
- 2. Identifica los problemas que has tenido antes. ¿Qué defectos llegan al cliente? ¿Qué hace que una tarea no esté lista? Esa es tu base.
- 3. Escribe una lista inicial (8-15 criterios máximo). Menos es más. Si es muy larga, nadie la seguirá. Prioriza lo que importa.
- 4. Valida que sea alcanzable. ¿Tu equipo puede cumplir TODOS los criterios con los recursos que tiene? Si no, ajusta.
- 5. Publica, enseña y revisita cada 2-3 sprints. Pegalo en la pared, en Slack, en la sala de reuniones. Y actualízalo cuando aprendas.
Ejemplo práctico: DoD para una historia de desarrollo web
Historia: «Como usuario, quiero poder filtrar productos por precio para encontrar lo que busco rápidamente»
Definition of Done para esta historia:
- ✅ Filtro implementado en React/Vue con lógica separada del componente (buen diseño).
- ✅ Backend devuelve resultados filtrados con latencia menor a 500ms.
- ✅ Pruebas unitarias incluidas (test del componente, test de la API).
- ✅ Test manual completado: filtro funciona con 1, 10, 100 y 1000 productos.
- ✅ Código revisado y aprobado por al menos un senior.
- ✅ Merge a rama develop (no directamente a producción).
- ✅ Actualizado en Jira con etiqueta «Ready for QA».
- ✅ Documentación técnica breve en el repo (README o comments).
- ✅ Demo mostrada al Product Owner quien da aprobación.
Sin DoD: El desarrollador cree que está listo porque «compila», pero falta QA, documentación y revisión.
Con DoD: Todos saben exactamente qué falta antes de marcar como «Done».
Errores típicos que debes evitar
- ❌ DoD demasiado largo: Si tienes 30 criterios, tu equipo los ignorará. Máximo 15.
- ❌ Muy aspiracional: «100% test coverage» suena bien, pero si es imposible de lograr, nadie lo cumple.
- ❌ No actualizar nunca: Tu DoD de hace 2 años probablemente ya no aplica. Revísalo cada trimestre.
- ❌ Definirlo solo en el backlog: Sin consenso del equipo, no funciona. Todos deben estar de acuerdo.
- ❌ Ignorar el DoD en el sprint: Si lo incumples y no pasa nada, nadie lo respeta. Sé firme.
Variantes útiles para diferentes contextos
Para equipos Scrum puros:
Usa el DoD a nivel de historia + un DoD adicional a nivel de sprint (todo debe estar en producción, demo realizada, retrospectiva completada).
Para equipos Kanban:
Define un DoD por columna (Development DoD, QA DoD, Deployment DoD).
Para startups/equipos pequeños:
Un DoD simple y flexible: código funcional, revisado, testeado, documentado. Punto.
Conclusión:
El pequeño documento que define la excelencia
- Una Definition of Done bien hecha es tan simple como poderosa. No es un documento que se archiva en una carpeta olvidada—es el estándar vivo que tu equipo respeta cada día.
- Un proyecto sin DoD es caos disfrazado de productividad. Con DoD, tienes orden, calidad y confianza.
Lo mejor: Define tu DoD hoy. El segundo mejor momento es en tu próximo sprint.
