Los Criterios de aceptación son los elementos que permiten concluir la validez de una entrega. Por lo tanto, podemos entender que son elementos muy importantes para todas las partes que participan en el proyecto.

Podemos entender los criterios de aceptación cómo el elemento que permite al equipo ágil verificar el valor de aquello que hemos construido. En agilidad, la Sprint Review no tiene cómo objetivo validar “la técnica”, si no validar el valor. Y si lo que hemos construido da verdadera respuesta a las necesidades de los Stakeholders.

Podemos tomar los Criterios de aceptación cómo elementos de definición que añaden valor a diferentes niveles:

• Nivel Historia de usuario o ítem del product backlog: Una historia de usuario ha de poder evaluarse individualmente en función de unos criterios de aceptación que permitan demostrar su idoneidad.
• Nivel Sprint: El propio Sprint, en su conjunto, persigue la consecución de un valor suficiente (MVP) para poder plantear a la organización la entrega de una pieza que añadirá nuevas funciones al producto fabricado hasta el momento. Esta entrega ha de poder evaluarse bajo el prisma de unos criterios de aceptación que ayuden a validar la coherencia, la idoneidad y el valor obtenidos.

¿Quién define los criterios de aceptación?

Los criterios de aceptación plantean escenarios de prueba, desde la perspectiva del negocio, donde los stakeholders ponen a prueba la entrega, y lo comprueban en situaciones realistas de trabajo.

Los protagonistas en la validación, en un escenario realista de trabajo, no son otros que los Stakeholders. Y, por tanto, deberán ser ellos los principales responsables en la definición de estos criterios.

Ya sabemos que hemos de entender a los Stakeholders no únicamente cómo los usuarios, si no más bien cómo a todas aquellas partes interesadas en el producto que se está construyendo. Algunas de estas partes son muy próximas al negocio, y otras lo son de aspectos técnicos, tecnológicos u organizativos relevantes para la organización. Así, tenemos que los criterios de aceptación han de incluir elementos que nos permitan verificar, no únicamente la funcionalidad cruda, si no otros elementos importantes, cómo pueden ser:

• Diseño gráfico
• Usabilidad y accesibilidad
• Seguridad
• Cumplimiento legal y normativo
• Integración y convivencia con elementos preexistentes

¿Qué incluimos en los criterios de aceptación?

Los criterios de aceptación deben ser sencillos; y proporcionar información que nos permita hacer una verificación sin generar dudas. Los criterios de aceptación generalmente se componen cómo un texto que relata un escenario de prueba crítico. La superación del cual nos permite asegurar que aquello creado cumple las expectativas.

Respecto a cómo escrivir estos criterios para que sean una verdadera ayuda, (y no una fuente de conflicto por su interpretación), existe una buena práctica interesante llamada SMART

• S - Specific: El criterio ha de describir un escenario específico. Fácilmente acotable y entendible para todas las partes. Ni demasiado difuso que de pie a interpretación, ni demasiado atómico que proporcione un valor insuficiente a la prueba.
• M - Measurable: El criterio ha de proporcionar un escenario tal, que permita a los stakeholders valorar si el producto cumple o no cumple con los criterios establecidos.
• A - Achievable: La descripción del criterio de aceptación ha de ser posible dentro del escenario tecnológico, de recursos u organizativos en que el equipo trabaja. De nada sirve un criterio de aceptación que exige el uso de un repositorio de datos para los que el equipo no tiene acceso.
• R - Relevant: Si paso la prueba propuesta por el criterio de aceptación, he de entender que esta es de suficiente relevancia para que me permita concluir que el producto es válido desde mi perspectiva.
• T - Time-Boxed: Para poder verificar un criterio de aceptación, muchas veces es necesario disponer del entorno, herramientas y conjunto de datos necesarios. Esto no puede extenderse en el tiempo. Y, por tanto, hemos de ser conscientes que un criterio de aceptación tiene una vida limitada, donde el Sprint y sus actividades marcan de forma clara los puntos en que las personas del equipo deben intervenir.

¿Cuándo y donde se definen los criterios de aceptación?

La definición de los criterios de aceptación debe ser una tarea completamente entrelazada con la definición de la propia necesidad. Por tanto, los criterios de aceptación se dialogan y se especifican desde los primeros momentos en que el Product Owner decide que cierta necesidad es aplicable.

Sea cómo sea, al llegar al Sprint Planning, los criterios de aceptación han de ser completos y comprendidos por los técnicos; pera aquellas historias que entran en el sprint.

El Product Backlog es un lugar muy adecuado para hacer efectiva esta definición de los criterios de aceptación. Los Stakeholders hacen su definición, y consensúan con el equipo la viabilidad de su aplicación.

¿Cuándo participan los criterios de aceptación?

Hay tres actividades importantes donde los criterios de aceptación tienen especial relevancia:

• El Sprint Planning: Cuándo los técnicos deciden junto al Product Owner los diferentes elementos que formarán parte del Sprint, deben hacerlo con pleno conocimiento de los criterios de aceptación que aplican a cada elemento, y de forma global al propio Sprint. De forma previa, el Product Owner ha trabajado con los Stakeholders la construcción de estos criterios.
• El Sprint: Los técnicos, durante el Sprint, trabajan en la construcción de los diferentes elementos, con el punto de mira situado en los criterios de aceptación (de cada elemento y los del propio Sprint).
• La Sprint Review: En la Sprint Review, los Criterios de aceptación adquieren una especial relevancia. Ya que son la herramienta principal con la que los stakeholders trabajan para poder validar la entrega.