Criterios de Aceptación Claros | GitScrum
Escribe criterios de aceptación que eliminen ambigüedad y creen entendimiento compartido de qué significa listo.
7 min de lectura
Los criterios de aceptación definen cuándo una user story está completa. Criterios claros previenen conversaciones de "pensé que significaba...", reducen retrabajo y ayudan a testers a saber qué verificar. Buenos criterios de aceptación son específicos, testeables y acordados antes de que comience el desarrollo.
Formatos de Criterios
| Formato | Mejor Para | Ejemplo |
|---|---|---|
| Given-When-Then | Escenarios de comportamiento | Flujos de login |
| Checklist | Features simples | Campos de formulario |
| Reglas | Restricciones | Validación |
Given-When-Then
Formato de Escenario
FORMATO GIVEN-WHEN-THEN
═══════════════════════
ESTRUCTURA:
─────────────────────────────────────
GIVEN: Estado inicial/contexto
WHEN: Acción del usuario
THEN: Resultado esperado
EJEMPLO COMPLETO:
─────────────────────────────────────
Escenario: Login exitoso
GIVEN: Usuario está en página de login
AND: Usuario tiene cuenta activa
WHEN: Usuario ingresa credenciales válidas
AND: Hace clic en "Iniciar Sesión"
THEN: Usuario ve dashboard
AND: Mensaje de bienvenida aparece
AND: Sesión se crea con timeout de 30 min
Múltiples Escenarios
ESCENARIOS PARA LOGIN
═════════════════════
ESCENARIO 1: Login exitoso
┌─────────────────────────────────────────────────────────────┐
│ GIVEN: Usuario en página de login con cuenta activa │
│ WHEN: Ingresa credenciales válidas y hace clic en login │
│ THEN: Ve dashboard con mensaje de bienvenida │
└─────────────────────────────────────────────────────────────┘
ESCENARIO 2: Credenciales inválidas
┌─────────────────────────────────────────────────────────────┐
│ GIVEN: Usuario en página de login │
│ WHEN: Ingresa password incorrecto │
│ THEN: Ve mensaje "Credenciales inválidas" │
│ AND: Campo de password se limpia │
│ AND: Intento se registra para seguridad │
└─────────────────────────────────────────────────────────────┘
ESCENARIO 3: Cuenta bloqueada
┌─────────────────────────────────────────────────────────────┐
│ GIVEN: Usuario con 5 intentos fallidos previos │
│ WHEN: Intenta login nuevamente │
│ THEN: Ve mensaje "Cuenta bloqueada temporalmente" │
│ AND: Se ofrece opción de reset de password │
└─────────────────────────────────────────────────────────────┘
Formato Checklist
CHECKLIST DE CRITERIOS
══════════════════════
STORY: Formulario de contacto
CRITERIOS DE ACEPTACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ CAMPOS: │
│ ☐ Nombre (requerido, máx 100 caracteres) │
│ ☐ Email (requerido, formato válido) │
│ ☐ Teléfono (opcional, formato: XXX-XXX-XXXX) │
│ ☐ Mensaje (requerido, máx 1000 caracteres) │
│ │
│ VALIDACIÓN: │
│ ☐ Errores muestran debajo del campo con borde rojo │
│ ☐ Botón submit deshabilitado hasta form válido │
│ ☐ Todos los campos se validan antes de enviar │
│ │
│ ÉXITO: │
│ ☐ Mensaje de confirmación aparece │
│ ☐ Email enviado a soporte@empresa.com │
│ ☐ Formulario se limpia después de envío │
└─────────────────────────────────────────────────────────────┘
Formato de Reglas
CRITERIOS COMO REGLAS DE NEGOCIO
════════════════════════════════
STORY: Cálculo de descuentos
REGLAS DE NEGOCIO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ R1: DESCUENTO POR VOLUMEN │
│ ├── 10-19 items: 5% de descuento │
│ ├── 20-49 items: 10% de descuento │
│ └── 50+ items: 15% de descuento │
│ │
│ R2: DESCUENTO POR CÓDIGO │
│ ├── Código válido: aplicar % del código │
│ ├── Código expirado: mostrar "Código expirado" │
│ └── Código inválido: mostrar "Código no válido" │
│ │
│ R3: COMBINACIÓN DE DESCUENTOS │
│ ├── Máximo total: 25% de descuento │
│ ├── Se aplican en orden: volumen, luego código │
│ └── Se muestra desglose al usuario │
│ │
│ R4: RESTRICCIONES │
│ ├── No aplica a items en liquidación │
│ └── Mínimo de compra: $50 para usar código │
│ │
└─────────────────────────────────────────────────────────────┘
Criterios Buenos vs Malos
COMPARACIÓN DE CRITERIOS
════════════════════════
❌ CRITERIO MALO: "El sistema debe ser rápido"
PROBLEMAS:
├── No es medible
├── "Rápido" es subjetivo
└── No se puede verificar
✅ CRITERIO BUENO:
"La página carga en menos de 2 segundos en
conexión 3G (medido en Lighthouse)"
───────────────────────────────────────────────────
❌ CRITERIO MALO: "Usuario puede buscar productos"
PROBLEMAS:
├── No define comportamiento
├── No especifica qué se puede buscar
└── No define qué resultados esperar
✅ CRITERIO BUENO:
"GIVEN: Usuario en página de productos
WHEN: Ingresa texto en barra de búsqueda
THEN: Resultados filtran en tiempo real
AND: Muestra nombre, precio e imagen
AND: Máximo 20 resultados por página"
Edge Cases
CONSIDERANDO EDGE CASES
═══════════════════════
STORY: Subir imagen de perfil
CAMINO FELIZ:
┌─────────────────────────────────────────────────────────────┐
│ ☐ Usuario puede subir imagen JPG/PNG │
│ ☐ Imagen se muestra como avatar │
│ ☐ Imagen previa se reemplaza │
└─────────────────────────────────────────────────────────────┘
EDGE CASES (¡no olvidar!):
┌─────────────────────────────────────────────────────────────┐
│ ☐ Archivo muy grande (>5MB): error con mensaje claro │
│ ☐ Formato no soportado: error listando formatos válidos │
│ ☐ Imagen corrupta: error genérico de upload │
│ ☐ Sin imagen previa: slot vacío muestra placeholder │
│ ☐ Upload interrumpido: mensaje de reintentar │
│ ☐ Usuario sin conexión: mensaje offline │
└─────────────────────────────────────────────────────────────┘
Proceso de Escritura
FLUJO DE CREACIÓN DE CRITERIOS
══════════════════════════════
PASO 1: PO REDACTA BORRADOR
┌─────────────────────────────────────────────────────────────┐
│ • Basado en requisitos de negocio │
│ • Perspectiva del usuario │
│ • Camino feliz primero │
└─────────────────────────────────────────────────────────────┘
│
▼
PASO 2: REFINAMIENTO CON EQUIPO
┌─────────────────────────────────────────────────────────────┐
│ • Desarrolladores agregan viabilidad técnica │
│ • QA agrega edge cases y testabilidad │
│ • Diseño confirma UX │
└─────────────────────────────────────────────────────────────┘
│
▼
PASO 3: ALINEACIÓN
┌─────────────────────────────────────────────────────────────┐
│ • Todos entienden lo mismo │
│ • Sin ambigüedades │
│ • Estimable │
└─────────────────────────────────────────────────────────────┘
│
▼
PASO 4: DOCUMENTAR EN GITSCRUM
┌─────────────────────────────────────────────────────────────┐
│ • Agregar a la tarea │
│ • Versionar cambios │
│ • Referenciar en tests │
└─────────────────────────────────────────────────────────────┘
Criterios en GitScrum
TEMPLATE DE CRITERIOS EN GITSCRUM
═════════════════════════════════
┌─────────────────────────────────────────────────────────────┐
│ ## Criterios de Aceptación │
│ │
│ ### Escenario: [nombre del escenario] │
│ - **Given**: [contexto inicial] │
│ - **When**: [acción del usuario] │
│ - **Then**: [resultado esperado] │
│ │
│ ### Checklist Adicional │
│ - [ ] [criterio 1] │
│ - [ ] [criterio 2] │
│ │
│ ### Reglas de Negocio │
│ - [regla 1] │
│ - [regla 2] │
│ │
│ ### Fuera de Alcance │
│ - [qué NO está incluido] │
│ │
└─────────────────────────────────────────────────────────────┘
Checklist de Calidad
ANTES DE APROBAR CRITERIOS
══════════════════════════
☐ ¿Cada criterio es verificable (sí/no)?
☐ ¿No hay ambigüedad en el lenguaje?
☐ ¿Cubren el camino feliz?
☐ ¿Cubren casos de error importantes?
☐ ¿Son independientes de implementación?
☐ ¿El equipo completo entiende lo mismo?
☐ ¿Están documentados en la tarea?
☐ ¿Sirven como base para tests?