¿Criterios de aceptación o condiciones de satisfacción?

La satisfacción del usuario es clave para calidad y compromiso
cortesía de Pixabay

Hemos tenido mucho debate sobre si los criterios de aceptación son una práctica ágil.

Recordemos que la parte importante de las historias de usuario es la conversación. Cuando las visualizamos como descripción corta en un post-it lo que estamos haciendo es comprometernos a conversar sobre estas más adelante.

Algunas compañías buscan en los criterios de aceptación un lugar donde escribir una especificación detallada y precisa para mantenerse lo más cerca posible de especificaciones detalladas tradicionales. Lo hacen agregando detalle como criterios de aceptación en lugar de hacerlo de forma ágil, que consiste en agregar detalle dividiendo la historia en historias más pequeñas.

Imaginemos la siguiente historia de usuario:

Como viajero

Quiero seleccionar las fechas de ida y de vuelta

Para poder comprar los billetes de tren e ir de vacaciones

con los siguientes criterios de aceptación:

Comprobar que las fechas no son un momento previo a la mayoría de edad del usuario

Comprobar que las fechas no sean un momento anterior al actual

Comprobar que la fecha de vuelta no es anterior a la de ida

Comprobar que el formato fecha se corresponde al formato aceptado por el sistema (DD/MM/AAAA)

El término "criterios de aceptación" puede llevar a un equipo de desarrollo a que no se sienta involucrado en la definición de la historia. Simplemente puede que se limite a tomar cada uno de los criterios e implementarlos uno a uno. Si finalmente el resultado no se comporta como hubiéramos deseado es porque el Propietario del Producto no ha incluido algún criterio de aceptación faltante.

Mike Cohn habla de condiciones de satisfacción, como condiciones específicas de una historia de usuario y que definen lo que debe ser cierto para que ese elemento de la pila se considere hecho.

Utilizando condiciones de validación en la historia del ejemplo anterior quedaría:

El usuario puede operar cuando a la fecha de ida sea mayor de edad

El usuario puede comprar un billete cuando las fechas seleccionadas sean posteriores al momento actual

El sistema no permitirá avanzar al usuario en la compra si las fechas no son coherentes

El formato de fecha con el que opera el sistema es DD/MM/AAAA

Con el término "condiciones de satisfacción" el equipo está enfocado en resolver el problema del usuario en lugar de implementar los criterios definidos anteriormente. Toda implementación de una historia de usuario debe de comenzar con una conversación que culmina en la planificación de sprint, conversación en la que el equipo debe de hacerse preguntas como:

• ¿Cómo podemos ofrecer el mayor valor con el menor esfuerzo?
• ¿Cuál es la funcionalidad mínima que tenemos para ofrecer?
• ¿Cómo podemos abordar las necesidades del usuario?

Bajo esta perspectiva podemos entender la definición de hecho (DoD) como un conjunto especial de condiciones de satisfacción que se agregan a toda historia de usuario.

Aprender a utilizar condiciones de satisfacción puede tomar un poco más de tiempo al principio, pero vale la pena invertir en este esfuerzo, ya que un equipo comprometido con el producto siempre puede encontrar mejores soluciones que un Propietario del Producto que escriba criterios de aceptación en solitario.

En mi opinión las condiciones de satisfacción ayudan a enfocar en lo que importa, aunque ninguna de las dos opciones es mejor que la otra, depende de como se usen.