La Definición de Hecho (Definition of Done) permite:

• Tener siempre un producto «potencialmente entregable y usable» al finalizar cada iteración, con el mínimo esfuerzo, i.e. no dejar trabajo pendiente para el final, escondido “debajo de la alfombra”, que pueda impedir utilizar los resultados del proyecto lo antes posible.
  • Esto permite saber claramente en qué punto real se está del proyecto y tomar buenas decisiones al respecto sobre lo que se ha conseguido hasta ese momento y lo que todavía no se sabe con certeza cuándo estará acabado. Con una buena Definición de Hecho, el cliente podrá tomar decisiones correctas cuando al final de cada iteración el equipo le haga una demostración de los requisitos completados: cambiar las prioridades en función de la velocidad de desarrollo, solicitar una entrega del producto desarrollado hasta ese momento, etc.
  • Por otro lado, lo peor que podría suceder es que, aunque el equipo haya ido presentando todos los objetivos / requisitos completados durante el proyecto (en cada iteración), se podría dar el caso de que los días previos a una entrega de repente se den cuenta de que hay que hacer mucho trabajo de integración y finalización (que podría haberse ido haciendo antes, durante el proyecto). Esto también les dificultaría estimar cuándo tiempo necesitan para acabar de terminar el producto (lo cual pondría en peligro la fecha de entrega).

• Establecer un criterio de calidad, define qué entregables y mínimos de calidad tienen se tienen que cumplir en TODOS los objetivos / requisitos que se van a ir aceptando durante cada iteración del proyecto.

La Definición de Hecho se acuerda entre el Product Owner (cliente) y el Equipo de desarrollo al principio del proyecto y se puede ir mejorando durante su transcurso (si es necesario precisar más las expectativas en cuanto a calidad global o del proceso de trabajo o, simplemente, tras una Retrospectiva, para ir consiguiendo una mejor la calidad del producto final).

Ejemplo de Definición de Hecho:

• El trabajo de todos los miembros del equipo de desarrollo tiene que estar totalmente integrado en cada iteración.
• El trabajo de cada miembro del equipo ha sido revisado por al menos otro miembro del equipo.
• Todo el equipo considera que para cada objetivo/requisito se cumplen sus Criterios de Aceptación.
• El trabajo en cada iteración tiene que cumplir con los requisitos de calidad X, Y, Z.
• Tiene que estar probado A, B, C (calidad externa, usabilidad, funcionalidad, seguridad).
• El producto sigue los estándares de calidad interna y ha sido refactorizado para conseguir mantenibilidad.
• Tiene que estar documentado D, E, F.
• El Product Owner ha validado y aceptado el objetivo/requisito.

La Definición de Hecho en la “Fase de Planificación”

La Definición de Hecho se utiliza en la «fase cero» del proyecto (que incluye la «Inception» del producto, donde se genera la Lista de requisitos priorizada (Product Backlog) para que el equipo de desarrollo pueda realizar una buena estimación del esfuerzo global necesario para poder hacer todos los objetivos/requisitos del proyecto.

La Definición de Hecho en la Planificación de la iteración (Sprint Planning)

La Definición de Hecho tiene un impacto en tareas específicas a realizar en por el equipo de desarrollo en cada iteración, por lo que se utiliza como guía para generar tareas en la Planificación de la iteración (Sprint Planning) (además de los criterios de validación de cada objetivo/requisito).

Criterios de Aceptación vs Definición de Hecho

Cada objetivo/requisito tiene asociados sus criterios de aceptación, los cuales definen cómo se va a probar/demostrar que un objetivo/requisito ha sido conseguido. Se acuerdan entre el Product Owner (cliente) y el Equipo de desarrollo en una conversación que permita reducir la ambigüedad en QUÉ se espera sobre cada requisito / objetivo.

Los criterios de aceptación de los objetivos/requisitos a trabajar en una iteración se recogen en la Planificación de la iteración (Sprint Planning) (o antes, si fuese necesario, para empezar a preparar la información que se utilizará en el desarrollo del objetivo-requisito).

Notar pues que el concepto de “Definición de Hecho”, transversal a todos los temas (objetivos), es diferente del concepto de “Criterios de Aceptación, que afecta a cada tema (objetivo) en particular.

En cada iteración, el equipo revisa los criterios de aceptación de cada objetivo / requisito finalizado (y el cumplimiento de la Definición de Hecho general) antes de su aceptación por el Product Owner. Es decir, tanto el Product Owner como el equipo de desarrollo utilizan los criterios de aceptación (y la definición de hecho) como checklist para aceptar cada tema y darlo por hecho.