Definition de hecho: ejemplo, lista de verificación y taller en Scrum
El otro día preparé un taller junto con un colega. Rápidamente nos pusimos de acuerdo sobre el contenido, lo único que faltaba era una presentación PowerPoint adecuada. Para poder trabajar en la presentación de la forma más eficaz posible, la dividimos temáticamente. Cuando nos sentamos a discutir sobre el borrador terminado, se hizo evidente un gran problema: teníamos ideas muy diferentes sobre lo que realmente caracteriza a un “borrador terminado”.
Este problema también puede surgir en los equipos ágiles de Scrum. Al cabo de dos semanas, el equipo llega al final del sprint, pero hay desacuerdo sobre si el incremento del producto ya está terminado y puede pasar de “en curso” a “hecho”. Este desacuerdo da lugar a discusiones, que a su vez influyen negativamente en el clima del equipo. Para evitar estas discusiones y proteger un trabajo en equipo eficaz, existe un artefacto en el mundo Scrum llamado “Definición de Hecho” (DoD).
¿Qué es la Definition of Done en Scrum?
La Definition of Done es el acuerdo común de calidad de un equipo Scrum. Describe qué condiciones deben cumplirse para que un incremento se considere terminado y utilizable. No es una lista personal de tareas ni una aprobación adicional por parte de un solo rol, sino un estándar transparente para todo el equipo.
Literalmente, Definición de Hecho significa “definición de acabado”. Esto significa que el equipo se pone de acuerdo sobre lo que debe hacerse para que una característica se considere terminada. En términos prácticos, la Definición de Hecho puede representarse como una especie de lista de comprobación que se utiliza durante el sprint y especialmente al final para comprobar si se han cumplido determinados criterios de finalización. Para los equipos de desarrollo de software, estos criterios pueden ser, por ejemplo, los siguientes:
Ejemplo de Definition of Done: lista de verificación para equipos Scrum
Una Definition of Done práctica puede incluir, por ejemplo, los siguientes criterios para un producto de software:
- Los criterios de aceptación y los requisitos funcionales se han cumplido.
- Se ha preparado la documentación.
- El código está totalmente implementado y comentado.
- Se llevó a cabo una revisión del código.
- Las pruebas automatizadas se ejecutan correctamente; los errores relevantes y los riesgos de seguridad se han abordado.
- El cambio está integrado y puede verificarse en un entorno cercano al de producción.
- La supervisión, el registro de logs y, en su caso, las notas de lanzamiento se han tenido en cuenta.
- El incremento es utilizable y cumple el estándar de calidad del producto.
- …
Esta lista es un ejemplo, no una plantilla universal. Una buena DoD protege la calidad, sigue siendo aplicable para el equipo en cada Sprint y se ajusta cuando cambian el producto, los riesgos o las condiciones técnicas.
Definition of Done no es lo mismo que el impacto del producto
Una Definition of Done responde a una pregunta importante: ¿el incremento cumple el estándar de calidad acordado y es utilizable? Pero no responde automáticamente si el cambio logra el efecto deseado en el mercado o para el cliente.
Para la práctica, por eso ayuda distinguir entre tres niveles:
- Done: El incremento cumple la Definition of Done y puede utilizarse.
- Done-Done: El cambio está integrado, entregado y es observable en producción.
- Impacto del producto: El feedback real de los clientes muestra si el cambio resuelve un problema relevante y aumenta el valor del producto.
John Cutler describe el software por ello como un sistema de servicios desarrollado de forma continua: las funciones no son edificios definitivos, sino medios temporales para generar valor para el cliente. Lee su perspectiva en The Work Is Never Done.
Gil Zilberfeld también distingue entre distintos significados de «Done» —por ejemplo, cuando desarrollo, pruebas, entrega o feedback del cliente marcan cada uno un grado diferente de finalización. Encontrarás su clasificación en The Definition of Done, Done-Done and Really Done.
Importante: «impacto del producto» no debe formularse simplemente como un criterio adicional de DoD. Un equipo Scrum debe entregar un incremento utilizable; si logra el efecto deseado, se hará visible después mediante el Sprint Review, el uso y otros ciclos de aprendizaje. Precisamente esta separación evita que la Definition of Done se convierta en una lista acumulativa inalcanzable.
Cómo interactúa la Definition of Done con otras prácticas eficaces de Scrum, lo mostramos en nuestro artículo Scrum Best Practices 2026.
¿Por qué es importante una Definición de Hecho?
Que la fijación de objetivos tiene una enorme importancia para el rendimiento no es una idea nueva. La fijación de objetivos es un tema muy investigado en psicología (cf. Locke y Latham, 2006). Se ha demostrado que el rendimiento es mayor cuando los objetivos son lo más específicos y desafiantes posible, sin parecer inalcanzables. La Definición de Hecho no es, sin embargo, un método de fijación de objetivos (pero si se va a utilizar, es un método de fijación de objetivos). Apoyo en la fijación de objetivos Si necesitas ayuda, estaremos encantados de ayudarte); se trata más bien de una cuestión de criterios que hay que cumplir para conseguir el objetivo.
Estos criterios son importantes para crear un entendimiento común en el equipo. Comprensión de lo que cada miembro del equipo debe conseguir para alcanzar el objetivo común. Así que se trata de actuaciones individuales que, en última instancia, se suman a una actuación de equipo.
Si consideramos la cuestión de la DdD desde el punto de vista del propietario del producto, se ponen de manifiesto problemas completamente distintos. Si no se define claramente cuándo un incremento de producto se considera terminado, puede dar lugar a desacuerdos con el cliente cuando se le presente el producto. Si esto ocurre y se presenta un producto inacabado, se bloquea la posibilidad de respuesta del cliente.
Mejora continua
Puesto que una Definición de lo Hecho no es un concepto estático y puede y debe evolucionar o cambiar constantemente, también ofrece al equipo la oportunidad de aprender. Si, al final de un sprint, el equipo se da cuenta de que no ha podido cumplir los criterios de la Definición de Hecho, los miembros del equipo pueden ajustar la Definición de Hecho para que se ajuste al rendimiento real, o bien el equipo saca conclusiones para el siguiente sprint y cambia su forma de trabajar.
¡Prueba Echometer gratis ahora y obtén nueva inspiración para tus retrospectivas!
Estas reflexiones sobre la Definición de Hecho deben ser realizadas por el equipo durante la retrospectiva. Posible Artículos EchometerLas preguntas que pueden plantearse en la preparación son
Tenemos definiciones claras de Hecho para nuestros requisitos.
Suelo saber en qué punto estamos en la consecución de nuestros objetivos comunes.
Mis objetivos están alineados con los objetivos de mis colegas.
El equipo cubre todas las competencias que necesitamos para lograr nuestro objetivo.
No sólo se preguntan si existe una Definición de Hecho en el equipo, sino también cómo son la transparencia, la autonomía y la claridad de funciones en el equipo.
Puedes encontrar la lista completa de artículos en nuestra Herramienta retro.
¿Cómo puede nuestro equipo definir lo hecho? Un ejemplo de taller
Te hemos mostrado qué es una Definición de Hecho y por qué son importantes para una colaboración eficaz en los equipos Scrum. Pero si tu equipo aún no ha creado una DdD, probablemente te preguntes cómo funciona.
En principio, es importante que el equipo se tome su tiempo para preparar el documento. Al final, debe surgir un documento con el que todos los miembros del equipo puedan identificarse y que no se vea sólo como un mal necesario. Por lo tanto, recomendamos un formato tipo taller con el Scrum Master como moderador. Cada miembro del equipo debe pensar qué criterios son importantes para la realización del producto y el equipo puede resumir estas ideas. De forma análoga, hemos desarrollado un formato de taller para la fijación de objetivos. Echa un vistazo¡para obtener ideas para tu taller Definición de Hecho!
La DdD completada puede utilizarse en retrospectivas, por ejemplo, en forma de semáforo de Definición de lo Hecho:
- Escribe debajo tus criterios para la Definición de Hecho.
- Dibuja un cuadrado rojo, uno amarillo y uno verde al lado de cada uno.
- Para cada elemento de la Definición de Hecho, cada miembro del equipo marca si se implementó bien, medianamente bien o mal en el último sprint.
- Discute las tres con las menciones más frecuentes en la zona roja.
- Ajusta tu Definición de Hecho si es necesario.
Conclusión: ¿Terminado?
Unas palabras para concluir: no existe el “hecho” definitivo en el entorno ágil. Hecho sólo significa que algo está provisionalmente terminado, pero en cualquier momento puede y debe haber más ajustes y mejoras. Éste es uno de los muchos aspectos hermosos del trabajo ágil: la mejora continua.
Especialmente emocionante: a veces los puntos están “hechos” hasta que el cliente se presenta y cuestiona toda la solución, sacudiendo así tus cimientos de suposiciones sobre las necesidades del cliente. En tales situaciones, queda claro si el equipo ha priorizado realmente los beneficios para el cliente sobre el progreso en el sistema de tickets.
Una definición clara de lo hecho puede evitar conflictos y aumentar tu rendimiento. Si te interesan más formas de lograr este objetivo, también deberías echar un vistazo a nuestro artículo sobre la asombrosa verdad que se esconde tras la mentalidad ágil mira. O enriquece tus retrospectivas teniendo en cuenta los últimos descubrimientos científicos en psicología.
Exactamente con esta promesa hemos desarrollado nuestra retroherramienta Echometer. Si te interesa saber cómo (y si) funciona Echometer, lee el informe de la experiencia de Holger con nuestra herramienta:
¿Quieres llevar a tu equipo a un nuevo nivel de rendimiento? Nuestra Herramienta Retro puede ayudarte a hacerlo. Aquí tienes las experiencias de Holger con ella:
Informe de campo de Holger sobre la Herramienta Retro RemotaPreguntas frecuentes sobre la Definition of Done
¿Qué debe incluir una Definition of Done?
En una Definition of Done deben figurar todos los criterios de calidad que un incremento debe cumplir para ser utilizable. Ejemplos típicos son criterios de aceptación cumplidos, revisión de código, pruebas, revisión de seguridad, documentación y la posibilidad técnica de entrega. Qué puntos aplican lo decide el equipo para su contexto de producto.
¿Quién crea la Definition of Done en Scrum?
El equipo Scrum desarrolla y mantiene conjuntamente la Definition of Done. No debería ser impuesta por un solo rol como lista de control. Las organizaciones pueden establecer estándares mínimos, pero el equipo debe entenderlos y poder aplicarlos en su trabajo diario.
¿Cuál es la diferencia entre Definition of Done y Definition of Ready?
La Definition of Done describe cuándo un incremento está terminado y es utilizable. En cambio, una Definition of Ready puede contener criterios para la preparación de un elemento de trabajo, pero no es un artefacto oficial de Scrum y no debe servir para trasladar responsabilidades o ciclos de feedback.
Ejemplo práctico: Nuestra Definition of Done interna en Echometer
Una Definition of Done no tiene por qué terminar en el código y las pruebas. Internamente, Echometer utiliza un estándar más amplio que, además de la funcionalidad, también tiene en cuenta la UX, la mantenibilidad, la observabilidad y la preparación del lanzamiento. El siguiente ejemplo muestra cómo un equipo puede hacer que sus propios criterios de calidad sean concretos y verificables:
| Ámbito | Criterios de ejemplo |
|---|---|
| Funcionalidad | La funcionalidad especificada funciona, se han comprobado los casos límite típicos, no hay errores conocidos, las funciones inacabadas están protegidas mediante Feature Flag y se recopilan datos de uso relevantes. |
| UX | Se tienen en cuenta los estados vacíos, los estados de carga, los permisos, el manejo de errores, la localización y la visualización responsive. |
| Mantenibilidad | Se cumplen las Coding Guidelines y las convenciones relevantes, se ha evitado el código innecesario y la deuda técnica dejada intencionadamente, y hay información importante para el monitoreo y el debugging. |
| Despliegue | El cambio se ha desplegado en producción o se ha preparado deliberadamente mediante Feature Flag, las Release Notes se han añadido y las partes interesadas afectadas se informan cuando es necesario. |
Este ejemplo, por supuesto, no es una plantilla de validez general. Sin embargo, podéis usarlo como base, enriquecerlo con vuestras propias definiciones, revisarlo regularmente y desarrollarlo como un documento vivo.
Fuentes
Locke, E. A., & Latham, G. P. (2006). New Directions in Goal-Setting Theory. Current Directions in Psychological Science, 15(5), 265–268. https://doi.org/10.1111/j.1467-8721.2006.00449.x
