Una iniciativa digital puede estar técnicamente desplegada y, aun así, no estar lista para que el negocio la apruebe. También puede ocurrir lo contrario: el resultado parece útil, pero deja sin resolver una dependencia, un permiso o una excepción importante. La causa suele ser que las partes usan la palabra «terminado» con significados distintos.
Definir criterios de aceptación antes de empezar permite acordar qué resultado se espera, cómo se comprobará y quién tendrá autoridad para validarlo. No sustituye la definición del alcance ni las pruebas técnicas: conecta la necesidad de negocio con una decisión de aceptación observable. Este marco ayuda a responsables de producto, negocio y tecnología a reducir desacuerdos y detectar vacíos antes de la entrega.
Separar objetivos, alcance y criterios de aceptación
Estos tres elementos responden a preguntas distintas. El objetivo explica por qué se impulsa el trabajo y qué cambio se busca. El alcance delimita qué se va a abordar y qué queda fuera. Los criterios de aceptación describen las condiciones verificables para decidir si un resultado concreto satisface lo acordado.
Por ejemplo, un objetivo podría ser facilitar que los clientes consulten el estado de sus pedidos. El alcance puede incluir una pantalla de consulta para pedidos activos, pero excluir la modificación de la dirección de entrega. Un criterio de aceptación podría especificar que, al introducir un identificador válido, se muestre el estado correspondiente y la fecha de actualización. El ejemplo no prescribe cómo construir la pantalla ni define por sí solo todo el proyecto: delimita una condición que debe poder comprobarse.
Antes de redactar criterios, confirma que el objetivo es entendible y que el alcance tiene límites explícitos. Si una necesidad no está incluida, no la dejes implícita. Aclararla evita que una expectativa posterior se interprete como un defecto de una entrega que nunca la contempló.
Redactar condiciones observables, no soluciones prescritas
Un criterio útil se puede comprobar mediante una acción, un resultado observable o una evidencia acordada. Evita expresiones como «fácil de usar», «rápido» o «funciona correctamente» si no se aclara qué significan en el contexto del producto. Son intenciones valiosas, pero dejan espacio para interpretaciones incompatibles.
En lugar de «la consulta debe ser intuitiva», define qué tarea debe completar la persona usuaria y qué resultado confirma que la completó. Si el objetivo incluye rendimiento, accesibilidad o seguridad, traduce cada expectativa a una condición relevante para el caso y establece cómo se evaluará. No inventes umbrales por conveniencia: acuerda los valores con quienes conocen la necesidad y las restricciones.
También conviene evitar imponer una solución técnica cuando el negocio solo necesita un resultado. «Usar un botón azul» suele ser una decisión de diseño, no una condición de aceptación funcional. En cambio, «la persona puede iniciar la consulta desde la página de pedidos» describe una capacidad que se puede validar sin cerrar innecesariamente alternativas de implementación.
Una redacción práctica puede incluir cuatro componentes:
- Contexto: qué situación o tipo de usuario se considera.
- Acción: qué debe ocurrir o qué tarea debe poder realizarse.
- Resultado: qué respuesta, cambio o información se espera observar.
- Verificación: qué evidencia permitirá confirmar el resultado.
No todos los criterios necesitan la misma estructura. Lo importante es que negocio, producto y tecnología puedan leerlos de forma consistente y señalar cómo distinguir una aceptación de un incumplimiento.
Incluir flujos, excepciones, permisos y dependencias
El flujo principal es un buen comienzo, pero no suele ser suficiente. Una definición que solo cubre el caso ideal puede dejar sin respuesta qué sucede ante datos inválidos, falta de resultados, permisos insuficientes o un servicio externo no disponible. Incluye los casos límite que cambien el resultado esperado, el riesgo o la decisión de aprobación.
Para identificar esos casos, recorre la experiencia desde la perspectiva de las personas usuarias y de la operación:
- ¿Qué ocurre si falta un dato necesario o tiene un formato no admitido?
- ¿Qué información puede consultar cada perfil y qué acción tiene prohibida?
- ¿Cómo se comunica que no hay resultados o que una operación no pudo completarse?
- ¿Qué dependencia externa puede impedir la validación y quién debe resolverla?
- ¿Hay estados intermedios, como una solicitud pendiente, que deban distinguirse de una confirmación?
No hace falta enumerar toda situación imaginable. Prioriza las excepciones que afecten a seguridad, cumplimiento, continuidad operativa, experiencia o alcance. Si una dependencia no está disponible durante la aceptación, acuerda por adelantado qué evidencia alternativa es admisible y qué riesgo queda pendiente. Una demostración con datos preparados, por ejemplo, no equivale automáticamente a validar una integración real; esa diferencia debe quedar clara.
Asignar responsables y evidencias antes de iniciar
Un criterio sin responsable de validación puede reabrir el debate al final. Para cada condición, identifica quién propone la necesidad, quién realiza o coordina la comprobación y quién toma la decisión de aceptación. En algunos equipos esas funciones recaen en personas distintas; en otros pueden coincidir. Lo decisivo es que la autoridad para aprobar no sea ambigua.
Define también qué evidencia servirá para decidir: una revisión de comportamiento, un registro, una demostración, un resultado de prueba o la confirmación de una persona responsable. La evidencia debe corresponder al criterio. Una captura puede mostrar una pantalla, pero quizá no pruebe que los permisos se aplican correctamente. Una prueba técnica puede confirmar una respuesta, pero no necesariamente que la información sea comprensible para el usuario previsto.
Una plantilla breve para cada criterio puede incluir:
- Identificador y descripción: condición única, concreta y sin términos vagos.
- Contexto y alcance: usuario, estado o situación que cubre; excepciones excluidas.
- Responsable de aceptación: persona o función que decide.
- Método y evidencia: cómo se comprobará y dónde quedará registrado el resultado.
- Estado y observaciones: aceptado, pendiente o no aceptado, con motivo y siguiente paso.
La plantilla no debe convertirse en documentación por sí misma. Si el registro no ayuda a decidir, coordinar o conservar la evidencia, simplifícalo.
Gestionar cambios y detectar ambigüedades
Los criterios pueden cambiar cuando aparece nueva información. Para evitar sorpresas, registra qué cambió, quién lo aprobó y qué efecto tiene sobre alcance, prioridad, dependencias y fecha prevista. Distingue un criterio aclarado —que hace explícita una expectativa ya acordada— de uno nuevo que añade comportamiento. El segundo puede implicar una ampliación de alcance y requiere una decisión, no una modificación silenciosa de la definición de terminado.
Antes de aceptar una entrega, revisa señales de ambigüedad. Expresiones como «debe ser completo», «según corresponda» o «sin errores» no indican qué comprobar. También son alertas los criterios que mezclan varios resultados independientes, no tienen responsable, dependen de un tercero sin plan o no especifican qué hacer ante un fallo. Divide condiciones mezcladas, concreta el resultado y acuerda el tratamiento de dependencias.
Si negocio y tecnología discrepan sobre un criterio, vuelve a la necesidad y al riesgo que intenta cubrir. Pregunta qué evidencia cambiaría la decisión y qué alternativa satisface el objetivo sin imponer una solución prematura. Si no se puede resolver antes de empezar, registra la cuestión como decisión pendiente, asigna responsable y establece cuándo debe cerrarse. No la escondas dentro de una frase genérica.
Un buen criterio de aceptación no garantiza por sí solo el éxito de una iniciativa, pero vuelve la aprobación más predecible. Cuando cada condición expresa un resultado observable, tiene responsable y cuenta con evidencia adecuada, los equipos pueden detectar desacuerdos antes, separar defectos de cambios de alcance y decidir con mayor claridad si algo está realmente terminado.