El concepto de "Criterio de Aceptación"

El concepto de «Criterio de Aceptación«, tan utilizado dentro del vocabulario ágil, no forma parte del core de Scrum. No lo vas a encontrar en la guía oficial de Scrum.

Sin embargo, sí que es una práctica establecida en la industria el utilizar este término para referirse a las condiciones que cada «ítem» del backlog necesita satisfacer para considerarse como «aceptado».

Es una buena herramienta para dar transparencia y establecer la comunicación entre el equipo y el cliente. También lo es para refinar qué condiciones hacen que eso que entregamos realmente se acepte.

Y es aquí donde suele haber muchos malentendidos fruto de los diferentes contextos que tenemos.

Vemos el criterio de aceptación utilizado como criterio de validación de que se ha «hecho el trabajo». Recordemos que en agilidad (más allá de Scrum o de cualquier otro framework) buscamos conseguir autonomía en el cómo (trabajo), y focalizarnos en el para qué (resultados).

Si orientamos la conversación del criterio de aceptación hacia el «validar que hago trabajo» no conseguiremos ese foco. De hecho, podemos conseguir hacer mucho trabajo sin aporte alguno y sin el impacto esperado.

Y esta disfunción genera con el tiempo varios anti-patrones clásicos:

• maximización del trabajo – a costa de crear ineficiencia en la entrega de valor (equipos al 100% entregando «cosas»… que no aportan)
• separación entre cliente – equipo
• vanity metrics que no sirven para orientar negocio
• …

Por ello, una herramienta que nos ha servido mucho para corregir la disfunción, es introducir el concepto de «criterio de éxito» en la conversación de «criterio de aceptación».

Mientras mantenemos la (necesaria) validación del trabajo hecho, añadimos el «criterio de éxito» definido como qué condiciones validan / evidencian que hemos conseguido «éxito» en eso que estamos diseñando hacer.

Es decir, vemos y evidenciamos valor en que el equipo reflexione en si el trabajo que habíamos planificado se ha hecho o no. Pero como todos sabemos, hacer un trabajo no siempre consigue el valor/impacto que se espera de él.

Y, para orientar / adaptar un negocio, un producto, una iniciativa, lo que es clave es evaluar si estoy consiguiendo el impacto/éxito que quería conseguir. Y si no, pivotar.

Esto genera otros impactos relevantes en los equipos y la organización.

• Y si «no consigo éxito»??
• El éxito depende de «otros factores» !
• Quiero que se valore mi trabajo!

Y eso, objeto de otros artículos, nos abre a otras conversaciones más transformadoras en la organización…

• Qué puedo hacer para incluir en el equipo esos «otros factores» ?
• Qué puedo hacer para que «no conseguir éxito» sea no un castigo, sino un estímulo para diseñar otras maneras de intentar conseguirlo.
• Cómo tengo que modificar el sistema de valoración.
• …

Ideas clave:

• El criterio de aceptación NO es parte del núcleo de Scrum.
• El criterio de aceptación es una herramienta para entender mejor la necesidad en la conversación equipo – cliente
• El criterio de aceptación debería servir para entender si esa necesidad se ha satisfecho, no para saber si un trabajo se ha hecho.
• Dado que en ciertos contextos, validar si un trabajo se hace es necesario, podemos caer en el error de que todos nuestros criterios de aceptación se focalicen en eso: validar trabajo.
• Para ayudar a reorientar este sesgo, utilizar el «criterio de éxito» funciona en ciertos contextos… Pruébalo !