Definition of done: el checklist que cierra el trabajo

El definition of done (DoD, o definición de hecho) es la lista de condiciones que todo trabajo debe cumplir antes de que el equipo lo marque como terminado: revisado por otra persona, verificado que funciona, documentado si hace falta y entregado donde deba estar. Es un acuerdo de calidad, no un trámite. Su función es reemplazar la pregunta subjetiva «¿ya está?» por una verificable: «¿cumple la lista?».

Sin DoD, cada miembro aplica su propio estándar. Para uno, terminado significa que el código compila; para otro, que pasó revisión y está en producción. Las dos versiones son sinceras y por eso el problema es sistémico, no de actitud: la mayoría de los re-trabajos de un equipo vienen de esa definición ambigua, no de gente descuidada. El clásico «casi listo» es la señal de alerta: casi listo no es un estado, es una ausencia de criterio.

En la práctica, el DoD vive pegado al tablero: en un tablero kanban bien montado, una tarjeta solo cruza a Hecho si cumple la lista completa. Si no la cumple, no está en Hecho con una nota disculpándose: está en su columna honesta, que suele ser En revisión. Esa frontera visible es lo que convierte el acuerdo en hábito.

Se confunden todo el tiempo porque las tres herramientas hablan de «cuándo», pero cada una opera en un momento distinto del ciclo de una tarea: antes de entrar (DoR), al cerrar (DoD) y sobre el resultado concreto (criterios de aceptación). Esta tabla lo ordena:

Regla mnemotécnica: el DoR es el control de calidad de entrada, los criterios de aceptación son el contrato del resultado y el DoD es el estándar de salida que aplica a todo. Si tu equipo solo puede tener uno hoy, elige el DoD: es el que evita reabrir trabajo.

Un DoD útil cabe en una pantalla y cada ítem se verifica en minutos. Este es un punto de partida para un equipo de 1 a 15 personas; recórtalo a tu contexto:

1. Cumple los criterios de aceptación. El resultado es el que se pidió, no una versión aproximada. En una historia de usuario esos criterios ya están escritos: basta cotejar.
2. Pasó una segunda mirada. Revisión de código, de diseño o de texto por otra persona —o por ti mismo con un día de distancia si trabajas solo—.
3. Fue verificado funcionando. Pruebas en verde o verificación manual del flujo completo, no «en mi computadora funciona».
4. Está en el entorno real. Desplegado, publicado o entregado donde lo va a usar la gente, no en una carpeta local.
5. La documentación quedó al día. Notas, instrucciones o material de apoyo actualizados si el cambio los afecta.
6. No deja cabos sueltos. Subtareas cerradas o devueltas al backlog con contexto, no olvidadas.
7. La tarjeta quedó al día. Movida a su columna final, con un comentario de cierre si aporta contexto.
8. Quien pidió puede verificarla en 2 minutos. Si el cliente o el compañero necesita media hora para comprobar que está hecho, falta algo.

Ocho ítems, no treinta. Si alguno no aplica a un tipo de trabajo, ese tipo de trabajo tiene otro DoD —y eso ya es una señal de que tienes dos flujos, no un ítem de menos.

No necesitas un taller con post-its: necesitas tus fracasos recientes. El mejor DoD no se inventa, se extrae de los trabajos que se reabrieron:

1. Lista los últimos 3 trabajos «terminados» que volvieron (5 min). Correcciones de cliente, bugs aparecidos al día siguiente, entregas rehechas. Ese material es oro: es tu DoD implícito fallando.
2. Anota qué faltaba exactamente en cada uno (10 min). No «faltó calidad», sino «nadie lo probó en móvil», «no pasó revisión», «el cliente no recibió instrucciones».
3. Convierte cada falta en una condición verificable (10 min). «Probar en móvil antes de marcar como hecho», no «cuidar la calidad». Si no puedes verificarlo en un minuto, no entra a la lista.
4. Publícalo junto al tablero y acuérdenlo (5 min). La regla operativa es una: lo que no cumple el DoD no cruza a Hecho. Sin excepciones «solo esta vez», porque esta vez es todas las veces.

Revísalo una vez al trimestre, o cuando se repita un tipo de re-trabajo nuevo: si algo vuelve a reabrirse, la lista tenía un hueco, y el hueco se convierte en ítem. El DoD es un documento vivo, corto por diseño.

Un definition of done no falla por falta de ítems, sino por exceso o por mal uso. Los tres patrones que lo destruyen:

• El DoD de 30 ítems. Cuando todo es obligatorio, nada lo es: el equipo empieza a marcar casillas en falso y el checklist deja de significar algo. Si tu lista no cabe en una pantalla, es una lista de deseos.
• Un DoD distinto por persona. «Para mí terminado es esto, para ti aquello» es exactamente el problema que el DoD existe para resolver. El estándar es del equipo; las diferencias se discuten, no se aplican en silencio.
• Confundirlo con el definition of ready. Si el checklist llena de condiciones la entrada en lugar de la salida, el efecto es bloquear el trabajo nuevo en vez de evitar re-trabajo. El DoD gobierna la salida; el resto son criterios de aceptación o filtros de entrada.
• Usarlo como herramienta de control. El DoD no existe para auditar personas, sino para proteger el resultado. En cuanto se usa para señalar culpables, el equipo aprende a esconder lo incompleto: el efecto contrario al buscado.

Si quieres un DoD que viva donde ocurre el trabajo —un tablero con límites WIP, checklists y procesos, guardado en tu propia carpeta en JSON local, sin cuenta ni nube— Hito está pensado para equipos de 1 a 15 personas.

👉 Prueba Hito gratis — define tu checklist de cierre y deja de reabrir trabajo terminado.