Definición de Terminado: Qué Es y Cómo Usarla
Consistencia en la Calidad: Establecer una definición de terminado compartida previene la confusión y mejora la calidad del trabajo en el equipo.
Mejor Pronóstico: Una definición clara ayuda a prever la velocidad con precisión y a planificar mejor los proyectos.
Errores Comunes: Evita hacer la definición demasiado detallada o no aplicarla, ya que ambos pueden causar problemas.
Pasos Prácticos: El artículo describe pasos concretos para crear una definición de terminado exitosa para equipos ágiles.
La definición de terminado (DoD, por sus siglas en inglés) es el estándar compartido que determina cuándo un trabajo está verdaderamente completo. Ayuda a prevenir brechas de calidad, retrabajos y sorpresas justo al final del sprint. He visto equipos de desarrollo perder la confianza, incumplir plazos y crear conflictos innecesarios porque cada quien tenía una interpretación distinta de "terminado".
En esta guía, aprenderás cómo crear una definición de terminado que alinee a tu equipo ágil, mejore la previsibilidad y fortalezca la calidad, junto con ejemplos prácticos, plantillas y errores comunes a evitar.
¿Qué es la definición de terminado?
La definición de terminado es un conjunto formal y compartido de criterios que un elemento o incremento del product backlog debe cumplir antes de que el equipo lo considere completo y potencialmente liberable. Piensa en ello como el contrato de calidad que tu equipo acuerda mantener en cada tarea, independientemente de su tamaño o complejidad.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Estas son las características clave de una definición de terminado efectiva:
- Transparencia: Todos en el equipo y los interesados clave pueden verla, leerla y consultarla en cualquier momento.
- Medible: Cada criterio es binario. El trabajo o lo cumple o no lo cumple, pero los umbrales que elijas para los criterios cuantitativos merecen una reflexión real. Un objetivo de cobertura de código del 80% es binario en su cumplimiento, pero la elección de 80% sobre 70% o 90% es una decisión que deberías tomar deliberadamente.
- Universalmente entendido: Cada integrante del equipo Scrum debe ser capaz de interpretar cada punto de la misma manera.
- Aplicado consistentemente: La misma lista debe aplicarse a cada entregable y elemento del product backlog.
- Alcanzable dentro de un sprint: Los criterios deben ser lo suficientemente realistas como para que el equipo pueda cumplirlos durante un solo sprint o iteración.
En los proyectos de desarrollo de software, los desarrolladores suelen ser responsables de la definición de terminado porque son quienes deben cumplirla. Dicho esto, el product owner y el scrum master deben contribuir.
Si tu organización tiene sus propios estándares de definición de terminado, cada equipo Scrum debe seguirlos como piso mínimo. Los equipos siempre pueden agregar criterios más estrictos, pero no pueden rebajar el estándar organizacional.
Por qué es importante la definición de terminado
Una definición de terminado clara importa porque previene que trabajo parcialmente terminado pase desapercibido y ofrece un estándar compartido de calidad.
Estas son algunas razones adicionales por las que una definición de terminado compartida es importante:
- Funciona como un filtro interno de calidad: Cada elemento debe superar el mismo estándar antes de considerarse completo. Esto evita que el trabajo a medio acabar se infiltre en tu incremento del producto y se acumule como deuda técnica.
- Elimina ambigüedades: Cuando el equipo comparte una misma definición, no se producen situaciones donde definiciones contradictorias afecten la velocidad o calidad del trabajo. Una definición de terminado compartida supone menos conflictos, menos sorpresas y demostraciones más claras.
- Mejora la previsibilidad: Cuando terminado significa lo mismo en cada sprint, puedes pronosticar la velocidad con confianza y planear entregas sin inflar las estimaciones para cubrir retrabajos.
- Genera confianza con los interesados: Cuando los product owners, líderes y otros interesados externos pueden ver que tu equipo aplica un estándar de calidad claro, confían en tus entregas.
- Previene el caos en la integración: Si trabajas de manera que el equipo deba integrar su trabajo en un incremento compartido, un entendimiento común de la definición de terminado es la base para lograr incrementos consistentes y liberables.
Cómo crear una definición de terminado
Estos son los pasos clave en el proceso de creación de una definición de terminado.
- Audita tu flujo de trabajo actual: Mapea cada paso por el que tu trabajo ya pasa antes de llegar a producción. Habla con desarrolladores, testers, diseñadores y cualquier otra persona que intervenga en el proceso. Descubrirás pasos informales de calidad que deberían formalizarse.
- Identifica los criterios de calidad irrenunciables: Decide qué actividades deben realizarse para cada entrega. Esto suele incluir revisión de código, pruebas automatizadas, actualizaciones de documentación y escaneos de seguridad. Sé honesto sobre lo que actualmente omites.
- Redacta la lista de verificación colaborativamente: Reúne a todo el equipo y desarróllala usando una pizarra o un documento compartido donde todos puedan agregar, cuestionar y refinar elementos en tiempo real. Una definición de hecho adoptada por consenso aguanta mucho mejor la presión que una aprobada por votación a pesar de objeciones.
- Valídala contra los estándares de la organización: Contrasta tu borrador con las políticas de calidad, requisitos regulatorios o estándares de la industria que tu producto deba cumplir. Si tu organización ya cuenta con una definición base de hecho, parte de ahí y ajústala.
- Hazla visible: Pon la definición donde el equipo trabaje a diario. Puede ser un póster en la pared, un mensaje fijado en Slack o un panel en tu herramienta de gestión de proyectos.
- Comprométete a hacerla cumplir: Una definición de hecho que se ignora cuando hay prisa es peor que no tener ninguna, ya que genera una falsa sensación de calidad.
Ejemplos de Definición de Hecho
A continuación, algunos ejemplos de definiciones de hecho para distintos tipos de proyectos:
Definición de Hecho para Proyectos de Desarrollo de Software
Los proyectos de software enfrentan una gran variedad de riesgos de calidad: bugs, vulnerabilidades de seguridad, regresiones de rendimiento y fallos de integración. La definición de hecho para un equipo de software debe cubrir el camino completo desde el código hasta un estado publicable.
Esto podría verse así:
- Todo el código escrito y revisado por al menos otro desarrollador
- Pruebas unitarias superadas con el umbral de cobertura acordado
- Pruebas de integración exitosas en el pipeline CI/CD
- Sin bugs abiertos de gravedad crítica o alta
- Documentación técnica actualizada para reflejar los cambios
- Código fusionado a la rama principal
- Product owner ha revisado y aceptado el trabajo
- Benchmarks de rendimiento cumplidos según los umbrales pactados
Definición de Hecho para Proyectos de Marketing
El trabajo de marketing suele tener dimensiones de cumplimiento, marca y medición que difieren de software.
Así podría verse la definición de hecho en un proyecto de marketing:
- Contenido revisado y aprobado por el equipo legal
- Lista SEO completada, incluyendo meta descripciones, texto alternativo y enlaces internos
- Todos los activos subidos al CMS y con el formato correcto
- Seguimiento analítico configurado y verificado en el entorno de pruebas
- Redacción final revisada por un segundo miembro del equipo
- Lista de verificación del lanzamiento de campaña firmada por el líder del equipo
Definición de Hecho para Proyectos de Diseño
Los equipos de diseño necesitan que su definición de hecho conecte la intención creativa con la entrega técnica. Si no existe, los diseños llegan a desarrollo incompletos, con especificaciones faltantes, comportamiento responsivo no validado o brechas de accesibilidad que se descubren demasiado tarde.
He aquí un ejemplo de definición de hecho para un proyecto de diseño:
- Diseño revisado según los estándares de accesibilidad WCAG 2.2
- Archivo de entrega preparado en la herramienta acordada con todas las especificaciones, activos y anotaciones
- Vistos buenos de las partes interesadas recibidos y documentados
- Componentes del sistema de diseño actualizados si se introdujeron nuevos patrones
- Comportamiento responsivo validado en todos los puntos de corte pactados
Definición de Hecho vs. Criterios de Aceptación
La definición de hecho es el estándar de calidad a nivel de equipo, mientras que los criterios de aceptación son los requisitos funcionales a nivel de característica.
Piense en la definición de terminado como la base que se aplica de forma universal, y los criterios de aceptación como algo único para cada elemento del sprint backlog o ítem del product backlog. Un ítem del product backlog se considera terminado cuando cumple tanto sus criterios de aceptación como la definición de terminado del equipo.
| Aspecto | Definición de Terminado | Criterios de Aceptación |
|---|---|---|
| Alcance | Se aplica a cada ítem del product backlog e incremento | Específico para una historia de usuario o ítem individual del product backlog |
| Responsabilidad | Perteneciente a los desarrolladores, con aportes de todo el equipo Scrum | Escrito por o junto con el product owner |
| Especificidad | Estándares generales de calidad para todo el trabajo | Requisitos funcionales detallados para una pieza de trabajo |
| Frecuencia de cambio | Cambia rara vez; se actualiza durante las retrospectivas de sprint | Cambia con cada nueva historia de usuario |
| Punto de control | Se revisa antes de marcar cualquier ítem como completado | Se verifica durante la revisión o prueba de aceptación de la historia |
Errores y Obstáculos Comunes
Aquí hay algunos errores comunes que debes evitar al crear definiciones de terminado:
- Omitir elementos para ir más rápido: Los equipos bajo presión de tiempo suelen saltarse criterios como la revisión de seguridad, pruebas de accesibilidad o documentación. Esto genera deuda técnica oculta que más tarde aparece como errores, retrabajo o problemas de cumplimiento.
- Hacer la lista demasiado granular: Una definición de terminado excesivamente detallada se convierte en una carga burocrática. Si tu lista tiene 30 elementos y los desarrolladores pasan más tiempo marcando casillas que desarrollando software, te has excedido. Sé lo suficientemente específico para que sea útil, pero lo bastante general para que sea práctica.
- Cambiar la definición de terminado por historia: El propósito de la definición de terminado es la consistencia. Las condiciones específicas de funcionalidad deben estar en los criterios de aceptación, no en la definición de terminado.
- No revisarla nunca: La definición de terminado debe evolucionar conforme maduran tus prácticas, cambian tus herramientas o crece tu producto. Sugiero revisarla en las retrospectivas al menos una vez por trimestre y ajustarla cuando el equipo identifique vacíos o problemas.
- No hacerla cumplir: Una definición que se omite cuando alguien importante lo pide es inútil. El Scrum master debe proteger la definición, incluso cuando un interesado quiera lanzar algo que no cumple con el estándar. Si los criterios se omiten regularmente, el equipo pierde confianza en la norma y deja de tomarla en serio.
- Confundir "terminado" con "desplegado": La definición de terminado regula si un incremento es publicable, no si ya fue publicado. Un ítem del product backlog puede estar terminado sin estar desplegado. No agregues "desplegado en producción" a tu definición de terminado a menos que tu equipo realmente se encargue del proceso de publicación de principio a fin.
- No hacerle referencia: Muchos equipos tienen una definición de terminado de manera técnica, pero si nadie la ha revisado desde que se creó hace seis meses, no está funcionando como estándar de calidad.
¿Qué sigue?
Mejora tus procesos ágiles y formas de trabajo con herramientas prácticas, plantillas y la experiencia de especialistas a través de una membresía gratuita de DPM, y fortalece los sistemas que ayudan a los equipos a entregar trabajo de calidad de forma consistente.
