La Definición de Terminado y el reto de compartir expectativas
Una desarrolladora dice que la funcionalidad está terminada. La persona que hace las pruebas todavía espera poder validarla. Operaciones necesita las instrucciones de despliegue. El área de negocio espera algo que sus usuarios puedan utilizar. Todos llevan días hablando del mismo trabajo, pero cada cual entiende algo distinto por «terminado».
La Definición de Terminado hace visibles esas expectativas. Llegar a un acuerdo puede ser difícil, sobre todo cuando el equipo es nuevo, realiza trabajos muy distintos o lo integran personas con trayectorias profesionales diversas. En mi experiencia, el acuerdo se vuelve más claro a medida que el equipo aprende en común. Para empezar a aprender necesita un criterio explícito que pueda aplicar al trabajo real.
Primera parte: para qué sirve la Definición de Terminado
Qué consigue una Definición de Terminado
La Definición de Terminado, o Definition of Done (DoD), expresa el nivel de calidad que debe alcanzar un trabajo para considerarlo terminado. En un equipo de producto, permite decidir cuándo un cambio puede formar parte del producto acabado. Escribir el código puede dejar todavía pendientes las pruebas, la integración u otras tareas necesarias. [4]
Una definición útil debería ayudar al equipo de cuatro maneras concretas:
- Hacer observable la calidad, de forma que las personas puedan explicar cómo se comprobó el resultado.
- Mostrar el trabajo pendiente, para que una implementación acabada no esconda verificaciones o integraciones sin terminar.
- Mejorar la planificación al tener en cuenta todo el trabajo necesario para alcanzar el nivel acordado.
- Generar confianza, de modo que las partes interesadas sepan con qué pueden contar cuando el equipo dice que algo está terminado.
Las palabras importan. Un criterio vago reproduce el problema original: «se ha probado adecuadamente» deja que cada cual interprete en privado qué significa «adecuadamente». En cambio, una referencia a un conjunto de comprobaciones acordadas, con resultados accesibles, da al equipo algo que puede examinar en común.
Su lugar en la agilidad
Los principios del Manifiesto Ágil destacan la entrega frecuente de software que funciona, la excelencia técnica, la colaboración y la mejora periódica. No prescriben una plantilla universal para la Definición de Terminado. Acordar un estándar explícito ayuda a aplicar esos principios: permite valorar si el trabajo que se presenta como terminado puede utilizarse y cumple las expectativas de calidad. [1]
Su papel formal en Scrum
En Scrum, la Definición de Terminado es el compromiso asociado al Incremento: el resultado utilizable que el equipo incorpora al producto. Describe las condiciones de calidad que debe cumplir ese resultado.
El Scrum Team establece una definición apropiada si la organización no dispone ya de una. Cuando existe un estándar organizativo, constituye el mínimo que hay que cumplir. Los Developers responden de su cumplimiento. Si varios equipos trabajan en el mismo producto, deben compartir la misma definición.
Un elemento del Product Backlog que no la cumpla no puede formar parte del Incremento, entregarse ni presentarse en la Sprint Review. Regresa al Product Backlog para que se considere en el futuro. Esto no convierte la Review en un trámite de autorización: un Incremento utilizable puede entregarse antes.
La definición se aplica durante todo el Sprint. La calidad no debe disminuir en el transcurso del Sprint. Scrum identifica tres responsabilidades: Product Owner, Scrum Master y Developers. La dirección de proyecto no constituye una cuarta responsabilidad de Scrum. Estas reglas delimitan el marco en el que el equipo desarrolla su acuerdo de trabajo. [2]
Cómo se define el final del trabajo en Kanban
La Guía Kanban describe un acuerdo más amplio llamado Definition of Workflow, o definición del flujo de trabajo. Incluye los elementos de trabajo, los puntos en los que empiezan y terminan, los estados por los que pasan, el control del trabajo en curso, las políticas explícitas para mover elementos y una previsión de cuánto deberían tardar.
Una Definición de Terminado puede expresar parte de esas políticas, aunque Kanban no exige la terminología de Scrum. Sí hace falta poner un límite claro: acabar el desarrollo y acabar el recorrido por todo el flujo pueden ser dos cosas distintas. El límite elegido determina también qué mide el tiempo de ciclo.
Por ejemplo, un flujo que acaba en «Listo para publicar» describe un resultado distinto de otro que acaba en «Publicado». Ninguna de esas etiquetas debería obligar a quien depende del producto a adivinar lo ocurrido. Precisarlas es una forma práctica de hacer explícito el flujo.
Kanban no exige trabajar en Sprints. Los equipos pueden aplicar y mejorar sus políticas continuamente. Si Kanban complementa a Scrum, aporta atención al flujo y la Definición de Terminado de Scrum sigue rigiendo el Incremento. [3]
Un estándar compartido que admite requisitos distintos
Aquí es donde definir «terminado» puede parecer imposible. ¿Cómo va a servir una sola definición para una funcionalidad nueva, la corrección de un defecto, un cambio en la documentación y una investigación?
Un buen punto de partida es distinguir tres preguntas:
| Acuerdo | Pregunta que responde | Ejemplo |
|---|---|---|
| Definición de Terminado | ¿Qué nivel de calidad debe alcanzar el trabajo terminado que se incorpora al producto? | Los cambios están integrados y superan las comprobaciones acordadas. |
| Criterios de aceptación | ¿Qué debe conseguir este elemento concreto? | Una exportación CSV respeta los filtros seleccionados e incluye las columnas acordadas. |
| Condiciones para dar por terminada una tarea | ¿Cuándo se ha completado esta actividad concreta? | Alguien ha revisado el cambio propuesto y ha dejado constancia de sus hallazgos. |
La definición común debe seguir siendo concreta. Los detalles que varían pueden quedar en cada elemento de trabajo. Un cambio de documentación y otro de código pueden exigir pruebas distintas, aunque ambos contribuyan a un producto que debe alcanzar el nivel acordado.
Del mismo modo, terminar una investigación puede consistir en responder a una pregunta acordada y documentar lo aprendido. Es un resultado útil. Terminar esa tarea de investigación, por sí solo, no demuestra que exista un Incremento utilizable. Nombrar el resultado con precisión evita que el estado de una tarea interna exagere el progreso del producto.
Cuándo establecer y utilizar el acuerdo
Conviene establecer una primera definición utilizable a tiempo para orientar el trabajo, idealmente antes de que el equipo comience su primer Sprint de entrega. Durante la Sprint Planning, usadla para hablar de lo que se puede terminar de verdad, contando la verificación, la integración y demás actividades necesarias.
Mantened ese acuerdo de un Sprint a otro. Reescribirlo solo porque empieza otro Sprint aporta poco. Dejadlo a la vista mientras trabajáis y utilizad la retrospectiva para descubrir qué parte de su redacción, de su aplicación o de las prácticas que lo sostienen necesita mejorar.
Si cambia la definición, explicad qué ha cambiado y cómo se aplica. Una expectativa de calidad no debería aparecer por primera vez cuando alguien pide que se acepte el trabajo. Tampoco debería desaparecer un requisito por el mero hecho de que, sin él, resulte más fácil marcar el trabajo como terminado.
Segunda parte: construir una visión compartida en un equipo que aprende
El ejemplo de ordenar una habitación
Imagina que le pides a un niño que ordene su habitación.
Guarda los juguetes en una caja y despeja un pasillo en el suelo. Ha hecho lo que entendió que le pedías. Unos minutos después anuncia que ya está ordenada.
Entras y ves ropa sobre la silla, libros esparcidos por el escritorio y una taza junto a la cama. Para ti, ordenar incluía llevar la ropa al cesto, devolver los libros a la estantería, llevar la taza a la cocina y limpiar la mesa.
Ambos teníais una imagen del resultado esperado. Nunca llegasteis a compararlas.
Antes del siguiente intento, podríais acordar unas condiciones observables: juguetes en la caja, ropa en el cesto, libros en la estantería, taza en la cocina y escritorio despejado y limpio. Incluso podéis mirar juntos un ejemplo. Ahora el niño tiene referencias mucho más claras para decidir por sí mismo si ha terminado.
La comparación trata de expectativas que nadie ha expresado. En un equipo profesional aportamos al mismo trabajo conocimientos y responsabilidades diferentes. Cada perspectiva puede revelar algo importante en lo que los demás aún no han pensado.
Por qué cuesta llegar a un acuerdo al principio
Un equipo que empieza a trabajar junto no tiene todavía una experiencia común de lo que suele salir mal. Alguien puede dar por supuesta la revisión entre compañeros, mientras que otra persona la considera un paso adicional. Un colega que ha mantenido sistemas en producción quizá espere instrucciones de recuperación que a nadie más se le ha ocurrido pedir.
Si el trabajo es variado, cuesta más. Una frase genérica como «terminado con un buen nivel de calidad» parece abarcarlo todo, pero apenas ayuda cuando surge un desacuerdo. En el extremo opuesto, una lista escrita enteramente para código de aplicaciones puede no tener sentido en un trabajo de documentación o investigación.
También la presión desincentiva la conversación. Hablar de calidad lleva tiempo y las dependencias pendientes pueden dificultar alcanzar el nivel deseado. La tentación es marcar el elemento como terminado y dejar lo que falta para después.
En este contexto, llamaría madurez a la capacidad del equipo de sacar sus supuestos a la luz, acordar qué pruebas sirven y reconocer con franqueza cuándo faltan. Pasar muchos años juntos no garantiza adquirir esa capacidad.
Invitar a participar a quienes dependen del producto
El acuerdo tiene que conectar la perspectiva del equipo con las expectativas de las personas que dependen de su trabajo. Involucrad al Product Owner y a las partes interesadas pertinentes al identificar necesidades de calidad, usabilidad y operación. Si una persona dirige el proyecto y coordina dependencias o informes de seguimiento, aseguraos de que sabe qué promete de verdad el equipo cuando marca algo como terminado.
Preguntad al cliente o a quien representa al negocio qué espera poder hacer con el resultado. Para alguien, pedir un informe nuevo significa «ver los datos en pantalla». Otra persona espera «obtener una exportación que Finanzas pueda utilizar sin corregirla a mano». Esa diferencia debe entrar en los requisitos del elemento antes de juzgar si está terminado.
Si hace falta una aprobación, explicitad quién la da y qué examina. «El negocio tiene que aprobarlo» es un último paso demasiado impreciso para dejarlo tal cual.
Cómo crear una primera definición que se pueda usar
Yo empezaría por un taller breve en torno a trabajos reales. La siguiente secuencia da al equipo algo concreto que discutir:
- Elegid algunos elementos terminados que luego exigieron trabajo imprevisto. Incluid, si es posible, distintos tipos de trabajo. Preguntad qué daba cada persona por terminado y qué quedaba en realidad.
- Separad las expectativas de calidad recurrentes de los requisitos particulares. Si una expectativa se repite en los cambios del producto, valorad incluirla en la definición común. Si describe el comportamiento de una sola funcionalidad, anotadla en el elemento correspondiente.
- Redactad condiciones observables. Sustituid «probado» por una descripción acordada de las comprobaciones y de dónde encontrar los resultados. En vez de «documentación completa», especificad qué información debe estar al día y quién la necesita.
- Probad el borrador con ejemplos reales. Recorred una funcionalidad, la corrección de un defecto y otro elemento menos típico. Comentad qué demostraría que cada criterio se cumple. Si nadie interpreta una condición de forma consistente, hay que revisarla.
- Comprobad si el equipo puede alcanzar el estándar. La falta de acceso, entornos, competencias o apoyo es un problema de entrega que requiere una solución. Haced visibles esas limitaciones en lugar de esconderlas tras un estado de «terminado».
- Aplicad la definición y examinad los resultados. Registrad los malentendidos que se repiten y los trabajos que hubo que rehacer de forma imprevista. Cuando aparezca una carencia, mejorad el acuerdo.
La primera definición puede ser breve si abarca las necesidades esenciales de calidad del producto. La sencillez debe proceder de una redacción clara y de un alcance deliberado, no de omitir comprobaciones necesarias.
Un ejemplo práctico en un equipo de software
Pensemos en un equipo que añade una exportación CSV a un producto de informes. Los criterios de aceptación de ese elemento podrían exigir que la exportación respete los filtros seleccionados, incluya las columnas acordadas y gestione de manera clara los resultados vacíos.
Junto con estos requisitos, el equipo podría utilizar la siguiente Definición de Terminado compartida. Es un punto de partida que habría que adaptar al producto y a sus riesgos:
- Se ha verificado el comportamiento acordado y están disponibles las pruebas de esas comprobaciones.
- Se ha revisado el cambio y se ha integrado en el producto.
- Se superan las pruebas de regresión acordadas y los defectos pendientes no rebasan los umbrales de calidad definidos para el producto.
- Se han comprobado los requisitos aplicables de seguridad, privacidad y accesibilidad con respecto a los estándares acordados.
- Están al día las instrucciones para usuarios y la información operativa afectadas por el cambio.
- El Incremento resultante es utilizable y puede entregarse sin que quede trabajo pendiente de esta definición.
El comportamiento concreto de la exportación pertenece a esa funcionalidad. Las expectativas de calidad compartidas volverán a aplicarse cuando el próximo cambio sea una corrección o una funcionalidad distinta.
Expresiones como «aplicables» o «comprobaciones acordadas» necesitan respaldo. Identificad los estándares y conjuntos de pruebas pertinentes. Acordad de antemano cuándo se aplica un criterio, qué evidencias exige y cómo documentar el motivo cuando no proceda. De lo contrario, una redacción flexible puede volver a dar lugar a interpretaciones privadas.
Cómo cambia la definición a medida que madura el equipo
Scrum Inc. describe la Definición de Terminado como un acuerdo que evoluciona con el equipo y advierte del peligro de rebajarlo ante la presión de un plazo. Esto apoya un aspecto importante de la madurez: el estándar debe recoger lo que el equipo aprende. [4]
Al principio, las mejoras pueden consistir principalmente en ganar claridad. Más adelante pueden apoyarse en nuevas capacidades: comprobaciones automatizadas, entornos más fiables, instrucciones operativas más claras o mejores maneras de probar la integración.
Por ejemplo, si cambios aparentemente terminados fallan repetidamente después de desplegarse, el equipo puede añadir una comprobación de integración e invertir en un entorno donde ejecutarla. La mejora requiere tanto fijar la expectativa como adquirir los medios para cumplirla.
Yo juzgaría el progreso por la reducción de sorpresas. ¿Se reabren menos elementos porque faltaba trabajo necesario? ¿Se descubren menos comprobaciones pendientes a última hora? ¿Disminuyen los desacuerdos sobre lo que incluye un resultado terminado? Son observaciones para aprender, no puntuaciones con las que clasificar a las personas.
Un acuerdo maduro puede ser más exigente sin hacerse mucho más largo. Algunos detalles pueden quedar en estándares claramente referenciados y pruebas automatizadas. Lo que importa es que las personas entiendan las condiciones y puedan mostrar que las han cumplido.
El trabajo terminado sigue necesitando opiniones de los usuarios
Un producto puede cumplir su estándar de calidad y aun así no solucionar el problema del cliente. Una exportación implementada correctamente puede ser difícil de encontrar, incluir información que nadie necesita o servir para un proceso que el negocio ya ha cambiado.
La Definición de Terminado da al equipo un punto de partida fiable para hablar del resultado acabado. Las opiniones de los clientes y las evidencias de su uso real ayudan a decidir si ese resultado aporta valor. Ambas conversaciones importan y ninguna debería quedar escondida detrás de una afirmación ambigua como «el cliente está contento».
Hacer visibles las expectativas antes de empezar
El ejemplo de la habitación muestra lo fácil que es terminar un trabajo según una expectativa que los demás no compartían. Un equipo puede evitar buena parte de esa confusión si habla pronto del resultado, anota las condiciones importantes y las comprueba de manera sistemática.
A mi juicio, una Definición de Terminado útil surge de conversaciones repetidas sobre trabajo real. Empezad por un acuerdo que la gente pueda usar, aprended de las situaciones en que falla y desarrollad las capacidades que permitan cumplirlo.
Antes de empezar el siguiente elemento, preguntad a las personas implicadas: «¿Qué pruebas nos convencerían de que esto está terminado?».