Definición de hecho
La definición de hecho (Definition of Done o DoD en inglés) es el conjunto de condiciones acordadas que debe cumplir un trabajo para poder considerarse terminado. Es el compromiso asociado al incremento en el marco estándar de Scrum: garantiza que lo entregado tiene la calidad suficiente para integrarse en el producto o sistema y, si procede, ser puesto en producción.
A diferencia de los criterios de aceptación, que son específicos de cada historia de usuario, la definición de hecho aplica a todos los incrementos por igual. Es explícita, conocida por todo el equipo y evoluciona con el tiempo: a medida que el equipo aprende y el producto madura, la barra de calidad sube.
Sin una definición de hecho clara, el equipo puede producir una nube de trabajo aparentemente terminado pero en un estado incierto, que complica las planificaciones y genera riesgos ocultos en la fecha de entrega.
Quién la determina
La definen conjuntamente los desarrolladores y el propietario del producto. El equipo de desarrollo aporta los criterios técnicos de calidad; el propietario del producto aporta los criterios de entregabilidad desde la perspectiva del cliente.
Niveles de aplicación
La definición de hecho puede aplicarse a distintos niveles de granularidad:
Tarea
- Implementada.
- El código escrito cumple estilos y directrices del proyecto.
- Pruebas unitarias realizadas.
- Integrada en el repositorio.
- Integra correctamente con el resto del sistema en el build.
- Gestor de tareas actualizado.
- Satisfechas las métricas acordadas: cobertura, análisis estático, etc.
- Aprobada por el tester.
Historia de usuario
- Todas las tareas asociadas están hechas.
- Incidencias detectadas en fase de desarrollo resueltas.
- Código documentado con comentarios relevantes donde aporten claridad.
- Documentación y otros requisitos del proyecto completados.
- Satisface los criterios de aceptación acordados.
- Pruebas de integración realizadas.
- Pruebas unitarias acumuladas y de aceptación superadas (manual o automáticamente).
Sprint
- Todas las historias planificadas están hechas.
- Revisión del sprint realizada y feedback de los interesados obtenido.
- Retrospectiva realizada e identificada al menos una acción de mejora.
- Aprobado por el propietario del producto.
Diferencias con los criterios de aceptación
Los criterios de aceptación se centran en cada elemento del backlog de forma individual: los define el propietario del producto para explicar qué espera de una historia concreta. La definición de hecho atañe a los incrementos en general: define el estándar de calidad mínimo que debe cumplir cualquier trabajo entregado.
Una historia puede satisfacer sus criterios de aceptación y aun así no cumplir la definición de hecho si, por ejemplo, el código no pasa el análisis estático o no está integrado correctamente.
DoD reforzada en equipos con IA
Cuando parte del código se genera con herramientas de IA, la definición de hecho estándar no es suficiente. Los equipos que trabajan con asistentes de código o agentes de IA necesitan añadir criterios específicos —lo que la guía Scrum en equipos con IA de Scrum Manager denomina DoD reforzada:
- Análisis estático: el código generado por IA pasa herramientas de análisis estático sin errores críticos antes de integrarse.
- No-duplicación: verificado que la IA no ha introducido código duplicado. La duplicación tiende a aumentar de forma significativa en proyectos asistidos por IA; el umbral recomendado es inferior al 5%.
- Seguridad: revisión de vulnerabilidades específica para código generado por IA.
- IA supervisando IA: utilización de agentes de IA como revisores automáticos del output de otros agentes, con semáforos y alertas.
- Revisión humana: un product builder (desarrollador) revisa y valida el código antes de que se integre, con especial atención a los errores sutiles que la IA introduce con apariencia de corrección.
Los prototipos generados con vibe coding o generación conversacional rápida no se consideran incrementos liberables: son artefactos de aprendizaje para validar hipótesis. Incluirlos en la definición de hecho sin pasar la DoD reforzada es una de las formas más habituales en que el código generado por IA se convierte en deuda técnica acumulada.
Error frecuente
Tener una definición de hecho que nadie consulta. Es habitual que los equipos acuerden una DoD en las primeras semanas y luego no la revisen ni la apliquen con consistencia. El resultado es que cada miembro del equipo aplica implícitamente su propia definición de "terminado", lo que produce calidad inconsistente entre historias e incrementos. La DoD no es un documento de inicio de proyecto: es un estándar vivo que debe estar visible y revisarse en cada retrospectiva.
Recursos
🎙️ Podcast Ep. 6: Definition of DoneScrum Manager Podcast · Spotify
📄 Definition of Done o definición de hechoScrum Manager Blog · mar 2023
📄 Scrum Master v.4.0Descarga gratuita · Scrum Manager
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.