¿Qué es la Definición de Hecho (Definition of Done)?

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. 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 al Equipo de Desarrollo a la hora de saber cuántos elementos del Product Backlog puede 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 del Equipo de Desarrollo 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 del Equipo de Desarrollo 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 de Desarrollo debe especificar una Definición de Hecho adecuada al producto de que se trate.

– Si hay múltiples Equipos Scrum trabajando sobre el mismo producto, los Equipos de Desarrollo de cada Equipo Scrum deben crear conjuntamente la Definición de Terminado. 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 incluyen en la demo de la Sprint Review, sino que vuelven al Product Backlog.

– ¿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.


Ejemplos de Definición de Hecho

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.


¿Cómo establecer la Definición de Hecho?

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 es diferente a los criterios de aceptación

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.


Ejemplo de pregunta tipo test de certificación Scrum Master relativo a la Definition of Done

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.

Comparte este post

Publicado por Sergio Rodríguez

Chief Product Officer and Product Consultant for several international startups throughout his career, such as Liftshare.com, Hiyacar and Cardmarket. Agile practitioner for over 10 years and PSPO III certified. Obsessed with creating products that people love.

Posts relacionados

los comentarios están cerrados

Recibe artículos sobre ágil y promociones en tu email.