Definición de hecho

La definición de hecho (DoD o Definition of Done en inglés) es la descripción de las condiciones que debe tener un trabajo para considerarlo terminado.

Descripción y características

• La determinan los desarrolladores y el propietario del producto.
• Se suele plasmar en una lista de criterios al que se someterá la historia o el sprint para confirmar si se puede considerar "terminado".
• Es explícita y conocida por todo el equipo. Dependerá del ámbito del negocio, pero algunos de los aspectos más habituales que se incluyen son funcionalidad, calidad, pruebas, documentación y retroalimentación del cliente. Es decir:
  • Todas las tareas o historias implementan la funcionalidad requerida de manera correcta.
  • Todas se han implementado con alta calidad técnica, cumpliendo con los estándares necesarios.
  • Todas se han probado y los errores encontrados se han resuelto.
  • Todo ha quedado documentado adecuadamente para su fácil comprensión y mantenimiento.
  • Y el cliente ha revisado y aprobado el incremento.
  • También es habitual, en empresas de software, que la Definición de Hecho incluya criterios de seguridad, privacidad, y compatibilidad. Es importante que el código cumpla con los estilos y directrices del proyecto.

Función

• Incluye criterios y acciones que agregan valor demostrable, y puede ir evolucionando conforme se aprende, para mejorar tanto los entregables como la forma de trabajar.
• Ayuda a mantener un nivel de calidad que beneficia al cliente y a los usuarios.
• Ayuda a controlar el avance del proyecto.

«Hecho» debe significar que está listo para usarse: para integrarse en el producto o sistema. Eso no sólo requiere que el incremento funcione, sino que esté probado, que sea seguro, etcétera.

Sin una buena Definición de Hecho podemos producir una nube de trabajo no del todo terminado o en un estado incierto, que complica las planificaciones, y genera riesgos ocultos que pueden poner en compromiso la fecha de entrega y la calidad del producto.

Diferencias con los criterios de aceptación

Nivel de concreción

Los criterios de aceptación se centran en cada elemento del backlog por separado.

• Están conectados a las historias de usuario.
• Son algo con lo que están familiarizados los product owners.
• Suelen expresarse en forma de lista, como un flujo o una serie de criterios.
• El propietario del producto los explica durante la reunión de planificación del sprint, y cubren lo que el cliente espera de la historia.

La definición de hecho atañe a los incrementos, en general. Una historia puede estar completada, pero eso no constituye un incremento. Por supuesto, las historias incluidas en el sprint deben ser funcionales, y lo que define si lo son o no son los criterios de aceptación. Pero eso no es suficiente para entregárselo al cliente.

• Se asegura de que los incrementos están «hechos» de verdad. Un incremento «hecho» es una entrega que se puede dejar cerrada con tranquilidad.

Formato

No existe un modelo estándar para escribir ni los criterios de aceptación ni la Definición de Hecho. Pueden apuntarse utilizando lenguaje natural, tal y como el product owner o la persona del equipo se exprese, o acordar entre todos un formato cómodo y que sirva a las necesidades del equipo. Lo que sí es importante es hacer un esfuerzo por ser concisos y descriptivos al sintetizar lo que se ha acordado durante las conversaciones.

Véase también

• Criterios de aceptación.
• Desarrolladores.
• Propietario del producto.
• Historia de usuario.
• Sprint.
• Scrum Manager Podcast | Episodio 6: Definition of Done.
• Scrum Manager Blog: Transcripción Scrum Manager Podcast | Episodio 6: Definition of Done.