Una de las grandes ventajas de Scrum, es reforzar en los equipos, la evaluación reiterativa en sus procesos. Lo que llevará a los equipos a generar una serie de acuerdos por medio de los cuales se buscará la mejora continua frente a sus necesidades y aspectos de mejora.
Dentro de esta serie de acuerdos se encuentran, entre otros, la Definición de listo y la Definición de terminado. La composición de estos acuerdos interrelaciona conceptos que pueden confundirse con los Criterios de aceptación (1). Será entonces necesario brindar las respectivas aclaraciones sobre estos temas y qué tienen en común.
En palabras sencillas la Definición de terminado es el mutuo acuerdo del equipo frente a ¿Qué significa terminado? ¿Qué significa que algo esté finalizado? ¿Cuándo se considera que algo se terminó? Esta definición puede estar complementada o inclusive impuesta bajo una visión empresarial. Organizacionalmente se puede establecer una definición de terminado para todos los equipos que hacen parte de un marco ágil escalado.
Sin embargo, a pesar de hacer parte de una estructura empresarial, es recomendado que los equipos internamente validen si esta Definición de terminado abarca lo que para ellos significa terminado o si deben complementarla con unos acuerdos internos y propios. Es de vital importancia resaltar que, si un PBI o potencial entregable no cumple su Definición de terminado, este no se vuelve un incremento (2). En cada una de las iteraciones, todo el equipo tiene la responsabilidad de verificar si el incremento generado efectivamente cumple la Definición de terminado, este acuerdo no es inamovible puesto que el equipo puede evaluar su estructura en las retrospectivas basado en su contexto actual. La Definición de terminado es uno de los acuerdos que sincronizan a los equipos e inclusive les permite evaluar si una historia de usuario puede o no finalizarse dentro de un sprint.
Las necesidades puntuales del cliente frente a una funcionalidad, una aplicación, un producto o un servicio son denotadas por medio de los criterios de aceptación. Los Criterios de aceptación le dan visibilidad al equipo de lo que el cliente espera poder hacer, ver o requiere. Es de suma importancia resaltar que estos vienen directamente del cliente, y es responsabilidad del Product Owner hacerlos claros y visibles. Si el Product Owner no trae estos Criterios de aceptación, deberán ser demandados por parte de los developers en las sesiones de refinamiento para las historias de usuario y durante el evento de planeación. En comprender el trabajo a realizar, su complejidad y sus particularidades, está el foco para cumplir las expectativas del cliente. Los Criterios de aceptación no son globales, cada uno de estos puede ser único para una o algunas historias de usuario, sin embargo, rara vez se consideran una generalidad, de aplicarse para todas las historias de usuario se debería incluir como un item de la Definición de terminado. Estos pueden ser descubiertos inclusive en la ejecución del sprint y se deben validar con el Product Owner.
Los equipos confunden la Definición de terminado con los Criterios de aceptación porque los dos son una lista de chequeo por medio de la cual se verifica si el trabajo realizado es o no un incremento. La confusión se encuentra en que los Criterios de aceptación hacen parte de la Definición de terminado.
La Definición de terminado es el común acuerdo de que algo efectivamente está completo y por ende es un incremento, además de constar de unos ítems a verificar, indudablemente uno de estos ítems es que se cumplan todos los Criterios de aceptación. De esta manera el equipo se enfoca frente a lo que internamente necesitan para considerar que lograron una entrega de valor y a su vez cumplieron con la expectativa del cliente.
La Definición de terminado y los Criterios de aceptación son listas de chequeo cuya función principal es denotar si el trabajo realizado hace parte o no del incremento de producto y por consiguiente es una entrega de valor.
Los Criterios de aceptación hacen parte de la Definición de terminado, no obstante, la definición de terminado es un común acuerdo del equipo de trabajo, mientras los criterios de aceptación son solicitudes puntuales del cliente frente a aspectos funcionales o no funcionales dentro de un producto o servicio.
El equipo para reducir incertidumbre debe exigirle al Product Owner los respectivos Criterios de aceptación para cada una de las historias de usuario, y debe ensamblar su Definición de terminado basado en los procesos internos necesarios para entregar un incremento. La evaluación de la Definición de terminado para cada PBI es aplicada antes del sprint review, es el filtro para saber qué se va a demostrar en este evento y es modificable durante las retrospectivas. Los Criterios de aceptación no son modificables a menos que este cambio sea aprobado por los stakeholders claves. Estos dos conceptos son los que nos permiten reducir incertidumbre frente al trabajo a realizar y habilitan una conversación sana donde los desarrolladores pueden o no comprometerse a llevar a cabo un PBI del backlog.
Tabla comparativa | Criterios de Aceptación | Definición de Terminado |
Evento o actividad | Refinamiento y/o Planning | Retrospectiva |
Acordado por | Stakeholders: cliente o usuario | El Scrum Team |
Modificable | Si el cliente lo permite. | Si |
Generales para todas las PBI | No | Si |
Denota funcionalidades | Si | No |
Se relaciona con procesos de desarrollo | No | Si |
Se pueden modificar en durante el sprint | Si | No |
Referencias: