La Definición de Hecho o Definición de Terminado (Definition of Done) son aquellos requisitos que un elemento del Product Backlog y la totalidad del Incremento tienen que cumplir para considerar que el trabajo de desarrollo asociado ha concluido. Tales requisitos suelen referirse a la calidad técnica y a aspectos regulatorios que afectan al producto. La Guía Scrum, en su actualización de 2020 (cuyo análisis puedes consultar aquí), indica que la Definición de Hecho es un “compromiso” asociado al Incremento y que “es una descripción formal del estado del Incremento cuando cumple con las medidas de calidad requeridas para el producto”. Los miembros del Equipo Scrum deben tener un entendimiento compartido de lo que significa que el trabajo esté completado, de manera que haya transparencia respecto al Incremento.
Varios aspectos a destacar en relación con la Definición de Hecho en Scrum son:
– Guía a los desarrolladores a la hora de saber cuántos elementos del Product Backlog pueden seleccionar durante la Sprint Planning. Cuanto más exigente o difícil de cumplir sea la Definición de Terminado, a priori, menor será la capacidad de los desarrolladores y menos elementos del Product Backlog podrá seleccionar para cada Sprint. Por ejemplo, si nuestra Definición de Terminado implica el lanzamiento en producción, pero el despliegue en este entorno es complicado y requiere de un gran esfuerzo, la capacidad de los desarrolladores resultará mermada. Lo adecuado en estos casos será automatizar la puesta en producción y buscar el continuous deployment en la medida de lo posible. Lograr este nivel de automatización supondrá una inversión en el corto plazo que seguro que merecerá la pena.
– Si la Definición de Terminado para un Incremento es parte de los estándares de la organización, todos los Equipos Scrum deben seguirla. Si no es una convención de la organización, el Equipo Scrum debe especificar una Definición de Hecho adecuada al producto de que se trate (este es un cambio respecto a la Guía Scrum de 2017, que señalaba que era el Equipo de Desarrollo el que debía crearla; ahora es el Equipo Scrum en su totalidad quien ha de crear la Definición de Terminado).
– Si bien la Definición de Hecho es creada por el Equipo Scrum, son los desarrolladores quienes han de ajustarse a ella para completar el trabajo del Sprint.
– Si hay múltiples Equipos Scrum trabajando sobre el mismo producto, deben definir y cumplir mutuamente con la misma Definición de Hecho. Los Equipos tendrán que compartir un mínimo en común, si bien no hay inconveniente en que alguno de ellos tenga una definición más exigente.
– No hay que esperar al final del Sprint para verificar que un elemento está hecho. Al contrario, cuanto antes esté terminado, mejor.
– Los elementos del Backlog que están parcialmente hechos al concluir el Sprint no se ponen en producción ni incluyen en la demo de la Sprint Review, sino que vuelven al Product Backlog para su consideración futura.
– ¿Con qué frecuencia cambia la Definición de Hecho? A medida que los Equipos Scrum maduran, se espera que su Definición de Terminado se ensanche con el tiempo, elevando sus estándares de calidad. En general, siempre que haya cambios relativos a la calidad técnica del producto, cambios legales, nuevos requerimientos no funcionales, etc., será el momento de ajustar la Definición de Hecho.
– Un foro adecuado para revisar la Definición de Hecho es la Sprint Retrospective -pregunta típica en los exámenes de certificación Scrum Master / Product Owner; en este artículo puedes consultar nuestra guía de preparación para PSM I-.
– No tener una Definición de Hecho adecuada puede ser sinónimo de ausencia de estándares técnicos. En otras palabras, puede llevarnos a acumular deuda técnica que afecte irremediablemente a nuestro ritmo de desarrollo y capacidad de innovación.
Cada empresa y cada equipo deben tener su propia Definición de Hecho, apropiada para el producto en el que trabajen. Algunos ejemplos pueden ser:
– Pasa los criterios de aceptación de la historia de usuario.
– Pasa los tests unitarios.
– Código peer reviewed.
– APIs públicas documentadas.
– Pasa todos los tests y no hay errores aparentes.
– Aprobado por el Product Owner.
– Documentación de soporte a usuario lista.
– Traducción a inglés y español.
– Está desplegado en producción.
-…
Lo ideal será que “terminado” se asemeje lo máximo posible a “disponible en producción”. “Terminado” debe significar que ya no resta ningún trabajo adicional para que la funcionalidad de ese elemento del Product Backlog esté integrada y pueda ser utilizada por el cliente o usuario.
Si el Equipo aún no cuenta con una Definition of Done, será conveniente hacer una sesión en la que establezcamos una Definición inicial -que, como decíamos antes, debemos revisar en la Retrospective siempre que sea necesario-. Los pasos a seguir durante esta sesión pueden ser los siguientes:
– Establecer categorías que ordenen cuándo ciertas tareas deben completarse; por ejemplo, tareas que han de completarse a nivel de elemento del Product Backlog, de Sprint y de despliegue en producción.
– Con esas categorías, utilizando una pizarra blanca y post-its o una herramienta virtual, pediremos al Equipo que identifique tantas tareas como sea posible dentro de cada una de las categorías. Podemos dar un timebox de unos 5 minutos para ello. No solo debemos traer a colación tareas de programación, sino también otras relacionadas con el negocio en general y estándares o políticas de la empresa -el Product Owner puede ser de gran ayuda aquí-. Para dinamizar esta parte de la sesión podemos utilizar una estructura liberadora como 1-2-4-All.
– Puesta en común para entender cada tarea, eliminar duplicados y añadir otras nuevas que puedan surgir.
– Pedimos a los miembros del Equipo que pongan un punto en cada tarea que piensen que será difícil o, incluso, imposible de terminar dentro de un Sprint. Hay que tener en cuenta que todos los aspectos que se incluyan en la Definición de Hecho tienen que estar terminados al final de cada Sprint. Procedemos a eliminar aquellos que no puedan acabarse en el Sprint, para así obtener una Definición de Hecho menos exigente pero más realista.
– A continuación, debemos centrar nuestra atención en aquellas tareas que acumularon más puntos, en búsqueda de fórmulas que nos permitan lograr compromisos y mantener la calidad del Incremento. Seguramente tendremos que dedicar tiempo durante los próximos Sprints para implementar mejoras que nos permitan robustecer la Definición de Hecho -por ejemplo, automatizando tests o la puesta en producción-.
– El último paso será acordar qué tareas mantenemos como parte de la Definición de Hecho.
La Definición de Hecho predica de todos los elementos que se incluyen en el Incremento de producto, esto es, se refiere al Incremento como tal. Por su parte, los criterios de aceptación se refieren a un elemento del Product Backlog o historia de usuario en particular, no a la totalidad del Incremento.
Ahora bien, como señalábamos en los ejemplos, que la historia de usuario cumpla con los tests de aceptación puede -y debe- ser parte de la Definición de Terminado.
La Definición de Hecho es un tema recurrente en las certificaciones para Scrum Master como PSM I (Professional Scrum Master I, de Scrum.org), así como para las certificaciones para Product Owner como PSPO I (Professional Scrum Product Owner). A continuación compartimos una pregunta del estilo a las que pueden aparecer en los exámenes de certificación.
How much work needs to go into each Product Backlog item that has been selected for the current Sprint?
a) As much as possible and if it was not completed, it will be immediately added to the next Sprint
b) As much as required to meet the Definition of Done and be part of a fully tested, releasable Product Increment
c) As much as instructed by the Scrum Master, following the specifications of the Product Owner
d) As much as each developer deems appropriate to have some functionality ready for testing
Si quieres preparar PSM I o PSPO I, puedes apuntarte a nuestros cursos o utilizar el simulador de tests de certificación.