logo
Retrospectivas
Póker de Planificación
Standups
Rompehielos
Precios
Tablero

El checklist de definicion de hecho que tu equipo realmente necesita

Equipo agil de pie alrededor de una pizarra con un checklist completado, chocando los cinco despues de terminar un incremento de sprintEquipo agil de pie alrededor de una pizarra con un checklist completado, chocando los cinco despues de terminar un incremento de sprint Todo equipo Scrum tiene un momento en el que alguien marca una historia como "hecha" y otra persona pregunta: "pero, escribiste las pruebas?" Esa brecha entre lo que una persona considera terminado y lo que el equipo realmente necesita es exactamente lo que resuelve una Definicion de Hecho. La Guia Scrum de 2020 elevo el DoD de algo opcional a un compromiso formal vinculado al Incremento. Sin embargo, la investigacion del Estudio de Rendimiento de Equipos de Producto de Ron Lichty muestra que solo el 45% de los equipos tienen un DoD creado por su propio equipo. El resto trabaja sin uno o sigue un checklist que alguien mas les entrego. La parte interesante: solo las definiciones de hecho creadas por el equipo se correlacionan con alto rendimiento. Las impuestas externamente no muestran correlacion alguna.

Que es realmente la definicion de hecho

El DoD es un estandar de calidad compartido que se aplica a cada pieza de trabajo que tu equipo entrega. No es lo mismo que los criterios de aceptacion.
Definicion de HechoCriterios de aceptacion
AlcanceUniversal, se aplica a todo el trabajoEspecifico de una historia
EnfoqueEstandares de calidad y procesoRequisitos funcionales
Quien lo escribeTodo el equipo ScrumProduct Owner (con aportes del equipo)
Ejemplo"Codigo revisado por al menos un desarrollador""El usuario puede filtrar por rango de fechas"
Ambos deben cumplirse antes de que una historia este completa. Los criterios de aceptacion te dicen que construir. El DoD te dice que tan bien debe estar construido.

Un checklist de definicion de hecho en tres niveles

No todos los equipos necesitan el mismo DoD. Una startup lanzando su MVP tiene necesidades de calidad diferentes a las de una plataforma de salud con requisitos de cumplimiento. Aqui hay un enfoque por niveles.

DoD principiante

Para equipos que recien comienzan con una definicion de hecho formal:

Codigo revisado por al menos otro desarrollador

Pruebas unitarias escritas y pasando

Sin nuevas advertencias ni errores del compilador

Criterios de aceptacion verificados

Codigo fusionado a la rama principal

Compila exitosamente desde el control de versiones

DoD intermedio

Para equipos con CI/CD establecido y algunos sprints de experiencia:

Codigo revisado por al menos otro desarrollador

Pruebas unitarias escritas y pasando

La cobertura de codigo no disminuye por debajo del umbral actual

Pruebas de integracion pasando

No quedan bugs criticos o de alta severidad

Criterios de aceptacion verificados de extremo a extremo

Desplegado en el entorno de staging

El Product Owner ha revisado y aprobado

Documentacion tecnica actualizada

Estandares de accesibilidad cumplidos

DoD avanzado

Para equipos maduros que despliegan a produccion cada sprint:

Codigo revisado por al menos otro desarrollador

Pruebas unitarias, de integracion y de regresion pasando

Cobertura de codigo mantenida o mejorada

Escaneo de vulnerabilidades de seguridad aprobado

Benchmarks de rendimiento cumplidos

Desplegado en produccion detras de feature flag

Monitoreo y alertas configurados

Documentacion orientada al usuario actualizada

Notas de lanzamiento escritas

Criterios de aceptacion verificados en produccion

Aprobacion del Product Owner completada

Equipo mirando un gran monitor que muestra un pipeline de CI/CD con marcas de verificacion verdes en cada etapa, representando puertas de calidad automatizadasEquipo mirando un gran monitor que muestra un pipeline de CI/CD con marcas de verificacion verdes en cada etapa, representando puertas de calidad automatizadas El nivel adecuado depende de tu contexto. Comienza con un checklist que tu equipo pueda cumplir consistentemente, luego sube el estandar con el tiempo. Agregar elementos que tu equipo omite rutinariamente solo entrena a todos a ignorar el DoD por completo.

Por que el DoD importa mas de lo que crees para la estimacion

Aqui es donde la mayoria de los articulos sobre la definicion de hecho se detienen. Pero el vinculo entre el DoD y la precision en las estimaciones es la razon mas subestimada para hacerlo bien. La Guia Scrum lo dice claramente: los desarrolladores pronostican con mas confianza cuando entienden su Definicion de Hecho. Cuando tu equipo estima una historia durante el planning poker, esa estimacion deberia incluir todo lo requerido para cumplir el DoD. No solo escribir el codigo, sino la revision, las pruebas, el despliegue, todo. Los equipos que estiman solo el esfuerzo de codificacion y luego descubren las actividades del DoD al final del sprint se sobrecomprometen consistentemente. El trabajo no tomo mas tiempo del estimado. La estimacion simplemente ignoro la mitad del trabajo. Cuando agregas nuevos elementos a tu DoD (como escaneo de seguridad o pruebas de rendimiento), espera que la velocidad disminuya temporalmente. Eso es saludable. Tu velocidad simplemente se esta volviendo honesta.

Cinco anti-patrones que socavan tu DoD

1. Configurarlo y olvidarlo

El equipo escribio un DoD hace seis meses y no lo ha revisado desde entonces. Las herramientas cambian y el producto crece. Revisa el DoD en tus retrospectivas aunque no lo cambies cada vez.

2. Creado por una sola persona

Un lider tecnico o Scrum Master redacta el DoD solo y lo presenta como definitivo. El resto del equipo nunca siente propiedad sobre el, asi que lo tratan como opcional. La solucion: construirlo juntos en un taller. Todos los que hacen el trabajo deberian opinar sobre lo que significa "hecho".

3. Demasiado vago para verificar

"El codigo es de buena calidad" y "pruebas realizadas" no son verificables. Cada elemento deberia tener una condicion clara de aprobado/reprobado. "El codigo pasa el analisis estatico con cero problemas criticos" es algo que puedes comprobar. "El codigo esta limpio" es cuestion de opinion. Persona mirando un checklist gigante con algunos elementos claramente marcados como hechos y otros ambiguos, ilustrando la diferencia entre criterios vagos y especificosPersona mirando un checklist gigante con algunos elementos claramente marcados como hechos y otros ambiguos, ilustrando la diferencia entre criterios vagos y especificos

4. Bajar el estandar bajo presion

Cuando los plazos se ajustan, los equipos a veces debilitan el DoD para lanzar mas rapido. La Guia Scrum de 2020 es explicita aqui: el DoD puede evolucionar para mejorar la calidad, pero no deberia debilitarse. Recortar esquinas en calidad no te acelera. Crea la ilusion de velocidad mientras acumula problemas para sprints futuros.

5. Confundir DoD con criterios de aceptacion

El DoD es universal. Los criterios de aceptacion son especificos de cada historia. Mezclarlos significa que pierdes el estandar de calidad o te olvidas de los requisitos funcionales. Mantenlos como checklists separados que funcionan juntos.

Como construir tu primer DoD

Si tu equipo aun no tiene una definicion de hecho, aqui hay una forma practica de crear una.
Comienza con lo que ya esta sucediendo
Pregunta a tu equipo: "Que hacemos ya antes de considerar algo como hecho?" Anota cada respuesta. La mayoria de los equipos ya tienen estandares informales que no han sido documentados.
Identifica las brechas
Observa los bugs recientes o incidentes en produccion. Que los habria detectado antes? Esas brechas se convierten en candidatos para nuevos elementos del DoD.
Mantenlo corto
Apunta a 6-12 elementos. Cada elemento deberia ganarse su lugar previniendo una categoria real de problemas. Si no puedes senalar un problema especifico que un elemento detectaria, eliminalo.
Hazlo visible
Publica el DoD donde el equipo pueda verlo durante la planificacion de sprint y el trabajo diario. Un checklist enterrado en una wiki es un checklist que nadie lee.
Revisalo en cada retrospectiva
Agrega un punto fijo en la agenda de tus retrospectivas. Pregunta: "El DoD detecto lo que necesitaba? Se escapo algo? Deberiamos agregar o eliminar elementos?"

Que hacen diferente los equipos de alto rendimiento

La investigacion de Ron Lichty apunta a un patron claro. Los equipos de alto rendimiento son duenos de su DoD y lo evolucionan deliberadamente. Tambien lo usan para mantener las estimaciones honestas en lugar de optimistas. Estos equipos automatizan la mayor parte del checklist posible. Las verificaciones de cobertura de codigo y el analisis estatico se ejecutan en pipelines de CI/CD junto con escaneos de seguridad. El DoD se hace cumplir por el sistema en lugar de por la memoria, lo que libera al equipo para concentrarse en los elementos que realmente requieren juicio humano, como si los criterios de aceptacion se cumplen desde la perspectiva del usuario. Los equipos mas maduros vinculan su DoD a resultados de negocio, no solo a estandares tecnicos. Martin Hinshelwood da un ejemplo: "En vivo en produccion, recopilando telemetria, apoyando o disminuyendo la hipotesis inicial." Ese es un equipo cuya definicion de hecho no es solo "el codigo funciona" sino "estamos aprendiendo de lo que lanzamos."

Para comenzar

Elige tres elementos del checklist principiante de arriba. Escribelos en una pizarra o ponlos en un documento compartido. Usalos durante un sprint. En la retrospectiva, pregunta que funciono y que falta. Agrega uno o dos elementos. Repite. Un DoD pequeno y consistente que el equipo realmente sigue supera a uno completo que todos ignoran. Construye el habito primero, luego sube el estandar. Y la proxima vez que alguien pregunte si una historia esta hecha, tendras una respuesta que no requiere una conversacion de 10 minutos. Si tu equipo usa planning poker para estimar, manten el DoD visible durante esas sesiones. Es la forma mas rapida de asegurarte de que las estimaciones reflejen el alcance completo de lo que "hecho" realmente significa.

Revisalo en cada retrospectiva de sprint. La mayoria de los sprints no cambiaras nada, pero el habito lo mantiene relevante. Actualizalo cuando encuentres brechas recurrentes de calidad o cuando nuevas herramientas hagan automatizables los elementos existentes.

La Guia Scrum dice que si una organizacion tiene un DoD estandar, los equipos deben seguirlo como minimo. Los equipos pueden agregar estandares mas estrictos encima. En la practica, cada equipo deberia ser dueno de los elementos mas alla de la linea base organizacional.

La Definicion de Preparado cubre si un elemento del backlog tiene suficiente informacion para comenzar el trabajo (requisitos claros, dependencias identificadas). La Definicion de Hecho cubre si el trabajo terminado cumple con los estandares de calidad. Preparado es la puerta de entrada, Hecho es la puerta de salida.

No. Si no cumple con el DoD completo, no esta hecha. Vuelve al backlog del producto. El trabajo parcialmente hecho nunca deberia presentarse en la revision de sprint ni contarse para la velocidad.
Última actualización el 10/02/2026