Los criterios de aceptación describen el comportamiento que debe ofrecer una historia concreta para satisfacer el alcance acordado. Redáctalos como condiciones observables: qué se muestra, qué acción se puede realizar y qué ocurre cuando esa acción no puede completarse. En una historia de revisión del pedido, esto implica especificar los importes, los cambios de entrega y los estados de error antes del pago.
Un espacio compartido para el equipo de producto permite que producto, diseño, ingeniería y QA debatan esas condiciones juntos. El ejemplo de compra siguiente desarrolla un conjunto breve de criterios, los convierte en escenarios Dado–Cuando–Entonces y los distingue de la Definición de Terminado y del trabajo que queda fuera de la historia.
Empieza por el resultado y el alcance
Utiliza una historia que identifique lo que necesita conseguir la persona: «Como cliente que ya ha comprado antes, quiero revisar mi pedido antes de pagar para poder corregir errores». En este ejemplo, el cliente ha iniciado sesión, tiene artículos en el carrito y una dirección de entrega guardada. La historia cubre el paso de revisión de un proceso de compra existente, no la creación de una cuenta ni una nueva integración de pagos.
Decide qué correcciones permite ese paso. Aquí, el cliente puede elegir un método de entrega disponible y volver atrás para editar el carrito o la dirección. Eliminar artículos directamente desde la revisión, añadir un código promocional y rediseñar la integración con el proveedor de pagos son decisiones aparte. Sin ese límite, «corregir errores» puede abarcar varias funciones que distintas personas dan por incluidas.
Un criterio como «el cliente puede revisarlo todo» oculta estas decisiones. Sustituye «todo» por los campos y las acciones concretos. Así, diseño sabe qué representar y QA qué comprobar, sin imponer cómo debe almacenar los datos el equipo de ingeniería.
Sustituye las palabras vagas por condiciones observables
«Comprar debe ser fácil» es un objetivo, pero dos personas pueden interpretarlo de forma diferente. Para esta historia, acordad las condiciones siguientes:
- Resumen del pedido: antes de continuar al pago, el cliente ve el nombre, la cantidad y el precio de cada artículo, además del subtotal, los gastos de envío, los impuestos, la moneda y el total.
- Cambio de entrega: al elegir otro método de entrega disponible, los gastos de envío y el total se actualizan antes de que el cliente continúe.
- Datos incompletos o entrega no disponible: si falta información obligatoria de la dirección o el método elegido no está disponible para ella, el cliente ve el problema y cómo cambiar la dirección o el método; no puede continuar al pago.
- Actualización del importe: mientras se solicita el precio de entrega, o si la solicitud falla, el cliente no puede continuar con un total desactualizado. Si hay un error, puede reintentar la solicitud y se conservan los datos del carrito.
- Vía de corrección: volver a editar el carrito o la dirección conserva el resto del pedido. Al regresar a la revisión, el resumen refleja los datos actualizados.
Estas condiciones describen el comportamiento previsto para este ejemplo. El equipo de producto sigue siendo responsable de decisiones como los métodos de entrega admitidos, el cálculo de impuestos y la disponibilidad de entrega en una dirección. Los criterios deben remitirse a esas reglas acordadas, no inventar una nueva política fiscal o de entrega.
Utiliza datos de prueba concretos para evitar dudas aritméticas. En un conjunto de datos de ejemplo, dos artículos de 20 USD suman un subtotal de 40 USD. El envío estándar cuesta 5 USD y el importe de impuestos devuelto para esos datos es de 4 USD: el total mostrado es de 49 USD. Para el envío exprés, los datos de prueba devuelven 9 USD de envío y 4 USD de impuestos, con un total de 53 USD. Son valores fijos del ejemplo, no una regla sobre tipos impositivos; se trata de comprobar que la revisión muestra de forma coherente los importes recibidos.
Distingue los criterios de aceptación, la Definición de Terminado y las exclusiones
Los criterios de aceptación se aplican al comportamiento concreto que se está debatiendo. La Definición de Terminado describe la calidad que debe cumplir el Incremento del producto en Scrum. Scrum.org distingue los criterios de aceptación de una historia de la Definición de Terminado: especificar la funcionalidad esperada no sustituye el estándar de calidad compartido por el equipo.
| Tipo de registro | Ejemplo de compra | Para qué sirve |
|---|---|---|
| Criterio de aceptación | Cambiar del envío estándar al exprés muestra el total recibido de 53 USD antes del pago. | Describe un comportamiento dentro del alcance de esta historia. |
| Condición de la Definición de Terminado | El cambio está integrado y ha superado la revisión y las pruebas de regresión que exige el equipo. | Aplica el estándar de calidad acordado al trabajo. |
| Nota de exclusión | No se incluye añadir un proveedor de pagos ni una función de códigos promocionales. | Evita que la historia incorpore trabajo aparte sin acordarlo. |
| Tarea de implementación | Conectar el componente de revisión con la respuesta de precios de entrega. | Describe el trabajo que el equipo de desarrollo prevé para implementar el comportamiento. |
Deja las exclusiones junto a la historia, pero no las cuentes como criterios de aceptación superados. «El rediseño del proveedor de pagos queda fuera del alcance» no demuestra que funcione la revisión del pedido. Del mismo modo, «crear un campo en la base de datos» puede ser una tarea, pero no explica qué debe observar el cliente.
Un método de entrega no disponible no equivale a una función excluida. Es un estado de error dentro del flujo elegido y necesita una decisión sobre su comportamiento. Pasarlo a «fuera del alcance» dejaría indefinido el recorrido del cliente. Si hace que la historia sea demasiado grande, divide el trabajo manteniendo un recorrido utilizable y acuerda explícitamente el nuevo límite.
Redacta una versión Dado–Cuando–Entonces
La estructura Dado–Cuando–Entonces resulta útil cuando una condición depende de un estado y una acción específicos. La referencia de Gherkin de Cucumber separa el contexto inicial, el evento y un resultado observable. Puedes utilizar esta estructura para aclarar la conversación antes de que alguien la vincule a pruebas automatizadas.
Escenario 1: revisar el pedido actual
- Dado que el cliente tiene el carrito de ejemplo, una dirección guardada completa y el envío estándar seleccionado,
- cuando abre la revisión del pedido,
- entonces el resumen muestra los artículos, la dirección, el método de entrega, el subtotal de 40 USD, el envío de 5 USD, los impuestos de 4 USD y el total de 49 USD.
Escenario 2: cambiar la entrega
- Dado que el cliente está revisando el pedido de ejemplo con envío estándar,
- cuando elige el envío exprés y la solicitud de precios se completa correctamente,
- entonces el resumen muestra 9 USD de envío y un total de 53 USD antes de permitir que continúe al pago.
Escenario 3: completar los datos de la dirección
- Dado que falta un campo obligatorio de la dirección,
- cuando el cliente intenta continuar desde la revisión,
- entonces se identifica el campo, se ofrece una acción para editar la dirección y el cliente permanece antes del pago, con el carrito conservado.
Escenario 4: recuperarse de un error al actualizar el importe
- Dado que el cliente ha cambiado la entrega y se está esperando un nuevo total,
- cuando falla la solicitud de precios,
- entonces la página explica que no se ha podido actualizar el total, ofrece reintentar e impide continuar al pago con el precio de entrega anterior.
Cada escenario responde a una pregunta. Evita uno largo que edite el carrito, cambie la dirección, aplique un descuento y realice el pago: si falla, cuesta más identificar la regla afectada. Añade otro ejemplo cuando haya una regla distinta que debatir, no solo para repetir la misma condición con otro nombre de cliente.
Resuelve las dudas antes de implementar
Pregunta a producto si las condiciones expresan el alcance deseado; a diseño, cómo se entenderán los estados; a ingeniería, qué dependencias pueden cambiar el comportamiento; y a QA, cómo se observará cada resultado. «¿Qué ocurre si ya no se puede entregar en una dirección guardada?» requiere una decisión de producto, no una expectativa de prueba inventada.
Separa las preguntas abiertas de los criterios acordados. Por ejemplo: «Si el método de entrega elegido deja de estar disponible, ¿preseleccionamos otro o exigimos una nueva elección?». La respuesta cambia tanto la interfaz como la prueba. Cuando el equipo decida, actualiza a la vez el criterio y el escenario afectados.
Si la información nueva cambia el alcance, registra la decisión en vez de eliminar en silencio una condición difícil. Si editar la dirección pasa a otra historia, la revisión del pedido sigue necesitando una vía clara para acceder a esa función y volver. Cumplir los criterios de aceptación tampoco deja sin efecto la Definición de Terminado del equipo.
Organiza la historia y los ejemplos en Boardmix
Coloca la historia en la parte superior de un tablero de Boardmix. Debajo, distribuye cuatro zonas: criterios acordados, ejemplos desarrollados, preguntas abiertas y exclusiones. Asigna un identificador a cada criterio, como AC-2 para el cambio de entrega, y sitúa su escenario al lado. Así se ve con más facilidad si una regla tiene un ejemplo y si una pregunta puede modificar una condición aceptada.
Mantén la Definición de Terminado compartida en una zona de referencia propia, en lugar de copiarla en cada escenario. Después de la conversación, el equipo puede trasladar los criterios acordados al registro de trabajo y conservar en el tablero las relaciones entre regla, ejemplo y decisión.
Abre un tablero de Boardmix para organizar la historia de compra y sus cuatro escenarios. Empieza por el cambio de entrega: permite detectar pronto si todo el equipo entiende lo mismo por «el total se actualiza».
