«El cliente puede aplicar un código de descuento al pagar» deja varias decisiones abiertas. El equipo necesita saber qué códigos son válidos, si se pueden acumular descuentos y qué ocurre cuando una promoción caduca mientras alguien está pagando. Los criterios de aceptación permiten concretar esas decisiones para que Producto, Ingeniería y QA revisen el mismo comportamiento antes de implementarlo.
Para un Product Owner, el punto de partida útil es el resultado que necesita una persona y las reglas que lo condicionan. Un criterio debe aportar contexto suficiente para comprobar si se ha conseguido el comportamiento acordado. Eso requiere conversar sobre casos concretos; añadir «funciona correctamente» a una tarea deja intacta la incertidumbre inicial.
Qué debe concretar un criterio de aceptación
Los criterios de aceptación describen las condiciones que debe cumplir un elemento de trabajo para responder a las expectativas acordadas. Pueden abordar una acción correcta, una restricción, un fallo o un requisito de calidad medible. Su redacción debe relacionar una situación identificable con un resultado observable, de modo que dos personas que revisen el mismo caso puedan discutir evidencias en lugar de interpretaciones distintas.
El Product Owner aporta a esa conversación el valor esperado y las reglas de negocio. Los desarrolladores contribuyen con las restricciones y las dudas de implementación, mientras QA ayuda a detectar casos pendientes y formas de verificarlos. Quién documenta el resultado puede variar. Scrum no prescribe una plantilla de criterios de aceptación ni exige que el Product Owner los redacte todos en solitario.
Un ejemplo de checkout: concretar las reglas del descuento
En este ejemplo hipotético, Mercato es una tienda en línea que introduce el código AHORRA10. El equipo acuerda que aplica un 10 % de descuento al subtotal de los artículos elegibles antes de añadir el envío, requiere un subtotal mínimo de 50 € y no se acumula con otra promoción. Son supuestos de este caso, no reglas universales para descuentos; el tratamiento fiscal y el redondeo requieren un acuerdo explícito con las personas responsables.
Los siguientes criterios convierten esos acuerdos en casos comprobables. Separan deliberadamente la validez del código, el cálculo y los cambios en la cesta, porque un código aceptado inicialmente puede dejar de cumplir las condiciones cuando el cliente elimina un artículo.
- Con 100 € de artículos elegibles y ninguna otra promoción, aplicar AHORRA10 muestra un descuento de 10 € y un subtotal de 90 € antes del envío.
- Con un subtotal elegible inferior a 50 €, el código no se aplica y el cliente ve la condición de compra mínima.
- Un código caducado o desconocido mantiene el importe sin cambios y muestra un mensaje que explica que no se puede utilizar.
- Si ya hay otra promoción aplicada, el producto informa de la incompatibilidad y no elimina la promoción anterior sin avisar.
- Si el cliente modifica la cesta, se recalculan las condiciones y el descuento antes de confirmar el pedido.
El límite merece una comprobación propia: según la regla acordada, un subtotal de 50 € debe cumplir la condición y uno de 49,99 € debe quedar fuera. El equipo también necesita concretar en qué momento se comprueba la caducidad y qué zona horaria se utiliza. Estos detalles pueden cambiar el alcance del trabajo. Resolverlos durante el refinamiento evita que una decisión de negocio quede en manos de quien implemente la última validación.
Cuándo ayuda el formato Dado–Cuando–Entonces
El formato Dado–Cuando–Entonces separa el contexto inicial, una acción o evento y el resultado esperado. Ayuda cuando una condición cambia el comportamiento, como los permisos del cliente o el estado de un pedido. Una lista breve puede resultar más clara para reglas independientes; forzar cada frase para convertirla en un escenario puede dificultar la lectura de un acuerdo sencillo.
Dado un carrito elegible de 100 € sin promociones activas, cuando el cliente aplica AHORRA10, entonces el checkout muestra un descuento de 10 € y un subtotal de 90 € antes del envío.
Esta redacción sigue la estructura que utiliza Gherkin, el lenguaje empleado por herramientas como Cucumber. Escribir una frase con ese formato no la convierte automáticamente en una prueba automatizada: los escenarios ejecutables necesitan código de prueba, datos adecuados y un entorno mantenido. Acordar ejemplos también puede ser útil cuando la primera comprobación se realiza de forma manual.
Un ejemplo de integración: la confirmación puede quedar pendiente
Mercato envía ahora un pedido confirmado a un proveedor logístico mediante una API. «El pedido se envía correctamente» deja sin definir el estado visible y el comportamiento de recuperación. Una respuesta que tarda puede significar que el proveedor no recibió la petición o que procesó el pedido y su respuesta se perdió. Si el producto interpreta ambos casos como un fallo definitivo y reenvía el pedido sin comprobarlo, puede generar trabajo duplicado.
- Cuando el proveedor confirma la recepción, el pedido registra su referencia y muestra el estado logístico acordado.
- Si se agota el tiempo de espera de la respuesta, el pedido muestra que la confirmación está pendiente; no aparece como un rechazo confirmado.
- Antes de volver a enviarlo, la integración comprueba si el proveedor ya tiene el pedido o utiliza un mecanismo para evitar duplicados que ese proveedor admita.
- Una persona sin el permiso logístico necesario no puede iniciar el envío ni consultar los detalles de pedidos de otro comercio.
Estos criterios requieren revisar las capacidades reales del proveedor. Si no ofrece una consulta fiable ni un mecanismo para evitar duplicados, el equipo debe acordar otro procedimiento de recuperación antes de prometer un reintento automático. La guía práctica de APIs explica los conceptos de petición y respuesta que sustentan esta conversación; autenticación y autorización distingue entre identificar a una persona y permitir una operación.
Criterios de aceptación y Definition of Done tienen alcances distintos
Los criterios de aceptación concretan las expectativas de un cambio, como qué descuento corresponde o qué significa una confirmación pendiente. La Definition of Done establece las medidas de calidad que debe cumplir el Incremento. Un descuento puede calcularse correctamente y, aun así, faltar comprobaciones exigidas por la Definition of Done del equipo. También puede ocurrir lo contrario: las comprobaciones técnicas comunes pasan, pero una regla de descuento acordada es incorrecta.
En Scrum, el trabajo que no cumple la Definition of Done no puede considerarse parte del Incremento. Cumplir los criterios de aceptación tampoco resuelve por sí mismo una decisión de lanzamiento: pueden quedar pendientes la activación progresiva, las dependencias externas o la preparación operativa. La diferencia entre desplegar un cambio y lanzarlo a los usuarios ayuda a situar esa conversación por separado.
Revisar los criterios antes de implementar
Una revisión útil consiste en pedir a alguien que no redactó el criterio que explique cómo lo comprobaría. Si necesita adivinar el estado inicial, inventar un valor de prueba o decidir qué significa «rápidamente», el acuerdo requiere más detalle. Para las expectativas de rendimiento, eso implica concretar un umbral junto con la carga y las condiciones de medición; el umbral aislado dice poco sobre la experiencia que se está comprometiendo.
Algunas preguntas quedan abiertas porque se desconoce el comportamiento de un proveedor o todavía no se ha decidido una regla de negocio. Conviene hacer visible esa incertidumbre y acordar quién la investigará, en lugar de ocultarla en una frase que parece definitiva. A medida que el equipo aprende, puede actualizar los ejemplos y discutir si cambia el alcance. Un requisito descubierto tarde debe examinarse de forma explícita, incluido su efecto sobre el trabajo ya acordado.
El libro Testing, bugs y calidad para Product Managers desarrolla la relación entre criterios de aceptación, resultados de pruebas y decisiones de calidad, tanto para Product Managers como para Product Owners. Para el caso de la integración, APIs para Product Managers amplía el contexto sobre errores, permisos y dependencias.
Referencias
- La Guía Scrum: Product Owner, Product Backlog y Definition of Done.
- Scrum.org: diferencias entre Definition of Done y criterios de aceptación.
- Cucumber: referencia de Gherkin y Dado–Cuando–Entonces.