---

¿Qué es la Definition of Done en el marco Scrum? ¡Puede que te sorprenda!

En el marco Scrum, la Definition of Done (DoD) establece los factores que determinan cuándo una funcionalidad está completada y cumple los estándares de calidad requeridos.

Como se ha explicado antes, las DoD especifican el resultado esperado en términos de requisitos funcionales y no funcionales, diseño, programación, pruebas unitarias, validaciones de usuarios finales, documentación, etc. Los equipos pueden utilizar criterios de aceptación de historias y listas de tareas para aclarar las expectativas funcionales, no funcionales y de trabajo.

Estos apoyan una Definition of Done común para el producto; no la sustituyen por un estándar de calidad distinto para cada elemento.

El equipo Scrum no puede cerrar historias de usuario ni tareas que no cumplan sus DoD. La Definition of Done (DoD) permite decidir si una historia del Sprint Backlog está completada. Es una lista completa de actividades necesarias para garantizar que solo se entreguen funcionalidades realmente terminadas, tanto en funcionalidad como en calidad. Las normas que utiliza un equipo para definir sus DoD pueden variar entre equipos, pero la Definition of Done del producto debe ser coherente. Los equipos que trabajan en un producto la comparten y cualquier estándar de la organización constituye el mínimo.

Las organizaciones pueden utilizar objetivos complementarios, criterios de aceptación o listas de comprobación en varios niveles. Son apoyos útiles para planificar, no sustitutos de la Definition of Done común del incremento:

• Lista del proyecto o producto (en los objetivos del proyecto)
• Lista del lanzamiento (en los objetivos del lanzamiento)
• Lista del Sprint (en los objetivos del Sprint)
• Criterios de aceptación de la historia de usuario (en la historia)
• Lista de tareas (en la tarea)

Otro aspecto esencial que conviene recordar es que una DoD no es estática ni incuestionable. Durante un proyecto, lanzamiento o Sprint, cualquier miembro del equipo Scrum u otra parte interesada del negocio o de TI puede cuestionar la DoD. Si los cambios propuestos tienen sentido y buscan el éxito del proyecto, el equipo Scrum y la Product Owner deben escuchar con apertura e implementarlos cuando corresponda, sin reducir la calidad ni marcar como completado un trabajo inacabado.