¿Qué aprenderas en este artículo?
La Definición de Hecho (DoD) es un elemento clave para mantener la transparencia, estabilidad y predictibilidad en los equipos Scrum.
¿Cómo se debe adaptar para alinearse con los cambios que introduce el desarrolo con IA? Te lo explicamos. 👇
⏱️ Tiempo de lectura: 4 minutos.
Próximos cursos relacionados
La Definición de Done es uno de los artefactos más poderosos de Scrum. Y uno de los más descuidados.
En muchos equipos, la DoD es una lista que se creó hace dos años, se aprobó en una reunión y desde entonces nadie ha tocado. Funciona como checklist de mínimos: ¿el código está en el repositorio? ¿Pasaron las pruebas? ¿Lo revisó alguien? Listo.
Si este artefacto podía usarse mejor en muchos equipos Scrum, con la IA formando parte del flujo de trabajo de muchos equipos, es todavía más crítico optimizar su uso.
Qué ha cambiado
Cuando un desarrollador escribe código con un asistente de IA, genera documentación con un modelo de lenguaje, o usa IA para crear casos de prueba automáticamente, el trabajo no ha cambiado solo en velocidad. Ha cambiado en naturaleza.
Aparecen preguntas que la DoD tradicional no contempla:
- ¿Quién ha revisado que el código generado por IA es correcto, no solo que compila?
- ¿Se ha verificado que los casos de prueba generados automáticamente cubren los escenarios que realmente importan, o simplemente los más fáciles?
- ¿Los datos que ha usado el modelo para generar una respuesta son fiables y actuales?
- ¿Se ha comprobado si hay sesgos en el output, especialmente si ese output afecta a decisiones sobre personas?
- ¿Sabe alguien del equipo por qué la IA tomó esa decisión, o simplemente se aceptó el resultado?
Si el equipo no tiene respuestas claras a estas preguntas, lo que ha entregado no está realmente Done. Está hecho. Son cosas distintas.
Lo que la DoD necesita incorporar
No se trata de añadir veinte líneas nuevas a la checklist. Se trata de hacerse las preguntas correctas y llegar a acuerdos explícitos como equipo. Estos son los aspectos que merecen atención:
Revisión de outputs de IA. Si el código, la documentación o los tests han sido generados o modificados significativamente por IA, ¿hay un criterio claro de revisión humana? ¿Quién lo revisa y con qué criterio?
Trazabilidad de las fuentes. Cuando la IA genera contenido basado en datos externos, ¿el equipo puede identificar de dónde viene esa información? ¿Es verificable?
Calidad del prompt. En algunos contextos, el prompt que se usó para generar algo es tan relevante como el output que produjo. ¿El equipo guarda, revisa o itera los prompts importantes como parte de su trabajo?
Comprobación de sesgos. En funcionalidades que afectan a usuarios reales —recomendaciones, clasificaciones, filtros— ¿el equipo tiene algún criterio para detectar que la IA no está amplificando sesgos no deseados?
Responsabilidad humana explícita. La IA puede sugerir, generar y optimizar. Pero la responsabilidad sobre lo que se entrega sigue siendo del equipo. ¿Está eso claro en la DoD, o la velocidad de entrega está diluyendo esa accountability?
Aspectos legales y de privacidad. ¿Se han considerado las implicaciones de usar determinadas herramientas de IA con datos de usuarios o clientes? ¿Cumple con lo que la organización ha acordado en materia de privacidad?
💌 Recibe estos artículos en tu buzón cada semana
El papel del Scrum Master en todo esto
La DoD no la escribe el Scrum Master. La crea el equipo. Pero el Scrum Master es quien más puede contribuir a que esa conversación ocurra, y ocurra bien.
Cuando la IA entra en el flujo de trabajo de un equipo, suele hacerlo de forma gradual y sin mucho debate. Alguien empieza a usar un asistente de código. Otro genera documentación con ChatGPT. Un tercero automatiza sus casos de prueba. Y de repente el equipo trabaja de una manera completamente distinta a cuando se definió su DoD, sin que nadie haya hablado de ello explícitamente.
Esa es exactamente la conversación que el Scrum Master puede y debe facilitar. No desde la posición de experto en IA —no hace falta serlo— sino desde su rol natural: hacer visibles los acuerdos implícitos, cuestionar lo que se da por supuesto, y ayudar al equipo a construir una transparencia compartida sobre cómo trabaja y qué significa realmente que algo esté terminado.
Una buena Retrospectiva centrada en este tema puede ser el punto de partida. Preguntas como «¿qué partes de nuestro trabajo han cambiado desde que usamos IA?» o «¿qué debería estar en nuestra DoD que aún no está?» suelen abrir conversaciones muy ricas.
Un ejemplo práctico: antes y después
Para hacer esto más concreto, a continuación hay un ejemplo ilustrativo de cómo podría evolucionar la Definición de Done de un equipo que ha incorporado IA en su flujo de trabajo. No es una plantilla ni una recomendación universal — cada equipo tiene su propio contexto, sus propias herramientas y sus propios riesgos. Sirve únicamente para visualizar qué tipo de criterios nuevos pueden aparecer y dónde encajan en una DoD ya existente. Los elementos marcados con ★ son los añadidos o modificados respecto a una DoD tradicional.
Definición de Done — Equipo de desarrollo de producto digital
Código y calidad
- El código ha sido revisado por al menos un miembro del equipo
- ★ Si el código ha sido generado o modificado significativamente con IA, la revisión incluye verificación de lógica y no solo de sintaxis
- Los tests automatizados pasan correctamente
- ★ Los casos de prueba generados con IA han sido revisados para confirmar que cubren los escenarios de negocio relevantes, no solo los técnicamente fáciles
- La cobertura de tests cumple el umbral acordado por el equipo
Documentación
- La funcionalidad está documentada según el estándar del equipo
- ★ Si la documentación ha sido generada con IA, ha sido revisada y validada por alguien con conocimiento del contexto real del producto
Calidad del output de IA (sección nueva) ★
- ★ Los prompts relevantes utilizados para generar outputs clave están registrados y disponibles para el equipo
- ★ Se ha comprobado que los datos o fuentes usados por la IA son fiables y actuales
- ★ En funcionalidades que afectan a decisiones sobre usuarios, se ha realizado una revisión básica de posibles sesgos en el output
Privacidad y cumplimiento (sección ampliada) ★
- ★ Se ha verificado que el uso de herramientas de IA cumple con la política de privacidad de la organización y la normativa aplicable
- ★ No se han procesado datos personales de usuarios a través de herramientas de IA no aprobadas por la organización
Responsabilidad y transparencia
- ★ El equipo puede explicar las decisiones tomadas en la funcionalidad entregada, incluyendo las que han sido influenciadas por outputs de IA
- La funcionalidad ha sido demostrada y validada con el Product Owner
- No hay deuda técnica nueva no registrada
Como se ve en el ejemplo, no se trata de reescribir la DoD desde cero. En muchos casos basta con añadir algunas preguntas que antes no eran necesarias hacerse, y que ahora sí lo son. La DoD sigue siendo del equipo. Lo que cambia es el nivel de honestidad sobre cómo se trabaja realmente.
Para terminar
La Definición de Done es un acuerdo vivo. No es un documento que se archiva; es una declaración de los estándares que el equipo se toma en serio. Si la forma de trabajar ha cambiado y la DoD no, hay una brecha. Y en esa brecha vive la deuda técnica invisible, los malentendidos con los stakeholders, y la ilusión de que se ha terminado algo que en realidad todavía no está listo.
Actualizar la DoD para reflejar el uso de IA no es burocracia. Es una señal de que el equipo está siendo honesto sobre cómo trabaja.
Si quieres explorar en profundidad cómo el Scrum Master puede ayudar a su equipo a adoptar la IA de forma efectiva y responsable, el curso Professional Scrum Master – AI Essentials (PSM-AIE) de Scrum.org aborda exactamente esto. Puedes consultar las próximas fechas aquí.
El curso Professional Scrum Product Owner – AI Essentials (PSPO-AIE) explica como este rol del equipo se ve afectado por la IA, y cómo puede utilizarla para multiplicar su impacto. Puedes consultar las próximas fechas aquí.