DOD son las siglas en inglés de Definition of Done, término de la metodología Scrum, que empezó a aparecer a partir de 2003, pero que se estableció realmente en los equipos de trabajo desde 2007. Todo equipo de desarrollo necesita una definición de lo que se considera hecho, si no estamos dejando algo tan importante a criterio individual de cada persona.
La Definition of Done (DOD) es el conjunto de criterios definidos por el equipo Scrum que determinan si una user story (o historia de usuario) puede ser considerada como hecha.
Es, por tanto, el acuerdo de buenas prácticas entre el Product Manager y el Equipo de Desarrollo para garantizar la calidad de la implementación. Porque sí, es responsabilidad de los desarrolladores definir esta lista, pero el Product Manager tiene que ser consultado para ir alineados con el resto de stakeholders.
El equipo se pone de acuerdo en la Definition of Done para:
- Proporcionar un criterio objetivo para decidir si una historia de usuario se ha completado o no.
- Evitar que el equipo empiece demasiadas cosas sin terminarlas.
- Contribuir a la calidad de lo producido, dando transparencia en lo que se entrega.
¿Y qué aspecto tiene una Definition of Done? Podemos crear una lista que sea visible para todo el equipo y permita su consulta a lo largo del sprint. Puede contener elementos como:
- La revisión del código se ha realizado.
- Las pruebas definidas en la historia de usuario se han llevado a cabo y han sido superadas, en particular por el equipo de QA.
- Revisión funcional con el Product Manager.
- Se han realizado las pruebas de resistencia.
- Se ha proporcionado la documentación necesaria.
- El código está desplegado en el entorno.
- Las dependencias están gestionadas.
- Se han respetado las creatividades y el Product Designer ha revisado los resultados.
- Se han desarrollado las medidas de contingencia en caso de tratar con una funcionalidad crítica.
- Se han desarrollado las métricas definidas.
- El código está documentado.
- El código cumple con los estándares de calidad de la compañía.
- No se incluye deuda técnica.
- Etcétera.
No debemos confundir el DOD con los Criterios de Aceptación, ambas cosas son complementarias.
Con el DOD marcamos las normas de calidad que se deben cumplir los desarrolladores, independientemente de quién integre, mientras que con los criterios de aceptación definimos las condiciones, los escenarios o comportamientos de la funcionalidad de cada historia de usuario en un lenguaje comprensible como Gherkin.
La DOD contribuye a la calidad del producto, reduce la deuda técnica y hace que tu producto sea escalable a largo plazo. Además, la DOD permite a los equipos de desarrollo conocer su capacidad de trabajo, ya que es necesario que una user story esté "Done" para que sus puntos puedan ser contabilizados en la velocidad de un sprint.
También podemos hablar de una user story "Done Done" cuando el lanzamiento de producción ha sido efectivo. Por ejemplo, si tu "Definition of Done" solo se refiere a la validación de la historia de usuario en sí misma sin que se haya incluido en una release.
Es aconsejable ir revisando el acuerdo de la Definition of Done en la retrospectiva de cada sprint, no solo para validar que se está cumpliendo, sino también para que evolucione y permita adaptarse a las habilidades y dependencias del equipo.
Para saber más: Descarga nuestro libro Las organizaciones orientadas a producto
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
