Respuesta.

Históricamente, la formulación de los criterios de aceptación ha estado en manos de los testers o del equipo de desarrollo. Sin embargo, con la transición a procesos ágiles escalables (SAFe, LeSS, Scrum-of-Scrums), sin escenarios de pruebas formalizados, surgen riesgos de discrepancias en las expectativas de los diferentes participantes en un gran proyecto: el negocio, la prueba, los desarrolladores y el soporte pueden interpretar de manera diferente la finalización de una tarea.

El problema en proyectos de múltiples equipos o distribuidos: diferentes áreas de responsabilidad, diferentes procesos y herramientas, diferencias lingüísticas o culturales entre los equipos. Incluso los requisitos bien elaborados pueden convertirse en criterios de aceptación conflictivos o incompletos, lo que lleva a errores y descontento empresarial.

La solución es involucrar al analista de sistemas en las primeras etapas de la formación de los criterios de aceptación, alineando requisitos entre los equipos, formalizando estrictamente y discutiendo conjuntamente los escenarios y edge cases en una demostración conjunta o taller grupal.

Características clave:

Los criterios de aceptación deben ser claros, medibles, reproducibles y validables.
Aprobación previa de los criterios (checklist manual + ejemplos de datos/comportamientos esperados).
Trazabilidad mutua: los criterios siempre deben referirse a requisitos, casos y user stories, para poder rastrear cada objetivo.

Preguntas con trampa.

¿Se puede dejar la formulación de los criterios de aceptación únicamente a los testers?

No, el analista debe participar. Solo él posee la totalidad del contexto empresarial y conoce todos los matices de los requisitos.

¿Deben cubrirse solo los escenarios positivos en los criterios de aceptación?

No, es obligatorio añadir casos negativos y límites (edge cases), de lo contrario, surgirán brechas en la implementación y prueba.

¿Se pueden definir los criterios de aceptación verbalmente en proyectos de múltiples equipos?

No, los acuerdos verbales no soportan la carga de la interacción distribuida y conducen a conflictos. Los criterios solo son aceptados formalmente (por ejemplo, en forma de Gherkin/BDD o listas de verificación estructuradas).

Errores comunes y anti-patrones

Formulación de los criterios de aceptación "por defecto", sin referencias a requisitos y especificaciones.
Falta de retroalimentación de los equipos finales.
Ignorar los escenarios de interacción entre componentes de diferentes equipos, especialmente en integraciones.

Ejemplo de la vida

Caso negativo: En una aplicación bancaria, los criterios de aceptación para la funcionalidad de transferencias se acordaron solo con un equipo. El segundo equipo implementó sus interfaces internas sin tener en cuenta el primer bloque de criterios, lo que llevó a una discrepancia en los formatos de ID de transacciones.

Ventajas:

Inicio rápido de la implementación.

Desventajas:

Necesidad de refactorizar la API.
Pérdida de tiempo en la resolución de colisiones.

Caso positivo: El analista llevó a cabo una serie de talleres con escenarios visuales y detalles para todos los equipos participantes, con una documentación escrita obligatoria de los criterios de aceptación en Confluence/JIRA con trazabilidad bidireccional a los requisitos.