Definición de hecho
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.
La definición de hecho en equipos con IA
Con la IA, la definición de hecho es el principal contrapeso a la velocidad: la IA produce trabajo con apariencia de terminado que puede contener errores sutiles, datos inventados o soluciones que funcionan hoy y causan problemas mañana. Por eso los equipos que trabajan con IA hacen su definición de hecho más exigente, no menos. El criterio central es la revisión humana: todo trabajo producido por la IA ha sido revisado por una persona que entiende lo que hace, y no solo que funciona o que parece correcto.
DoD reforzada
Muchos equipos añaden criterios específicos para el trabajo producido por la IA, lo que se conoce como DoD reforzada. Es una práctica en consolidación, no un requisito del marco estándar. Los criterios más frecuentes son:
- Verificación independiente: lo que produce la IA lo comprueba alguien o algo distinto de quien lo produjo.
- Procedencia visible: queda registrado qué partes produjo la IA y quién las revisó.
- Comprobaciones automáticas: en software, análisis automáticos de calidad, seguridad y duplicación; en otros equipos, comprobación de fuentes, de datos personales o de coherencia con la guía de estilo.
Algunos equipos usan una segunda IA como primer filtro (IA supervisando IA), pero nunca sustituye a la revisión humana.
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
🎙️ 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
📄 Scrum Master en equipos con IA v.1.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.