EARS + Agile y User Stories

EARS surgió en un dominio waterfall (aeronáutico) pero funciona excelente en Agile. La clave: User Stories describen valor para el usuario; EARS describe comportamiento del sistema. Son complementarios, no competidores.

Anatomía de una historia tradicional

Como <rol>,
quiero <acción>,
para <beneficio>.

Ejemplo:

Como administrador, quiero exportar la lista de usuarios a CSV, para hacer análisis en hojas de cálculo.

La historia es buena para el “por qué”. Pero no define:

• Qué columnas exporta
• Cómo se dispara la exportación
• Qué pasa si falla
• Cuánto puede tardar
• Quién más puede ver la exportación

Para eso están los criterios de aceptación — y ahí entra EARS.

Historia + criterios de aceptación EARS

Historia:

Como administrador, quiero exportar la lista de usuarios a CSV, para hacer análisis en hojas de cálculo.

Criterios de aceptación (EARS):

AC-1: Where the user has the role "admin", when the user clicks "Export users" in the admin panel, the export service shall generate a CSV file containing all users.

AC-2: The CSV file shall include the columns: id, email, role, created_at, last_login_at, status. The first row shall contain the column headers.

AC-3: When the export service generates the CSV, it shall complete within 10 seconds for up to 50000 users.

AC-4: If the export contains more than 50000 users, then the export service shall process it asynchronously and shall send an email with a download link valid for 24 hours.

AC-5: If a user is not an administrator and attempts to access the export endpoint, then the API shall return HTTP 403.

Notá que cada AC es testeable en aislamiento.

La INVEST de las historias y EARS

Las historias bien escritas son INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. EARS contribuye al último: Testable. Sin criterios de aceptación verificables, una historia no es testable.

flowchart LR
    Story[User Story] -->|necesita| AC[Criterios de aceptación]
    AC -->|escritos en| EARS[EARS]
    EARS -->|derivan a| Tests[Tests automatizables]
    EARS -->|también derivan a| Gherkin[Escenarios Gherkin]

Backlog Refinement y EARS

Durante el refinamiento, el equipo discute la historia y define los criterios de aceptación. Si el Product Owner los escribe en prosa libre, el refinamiento gasta tiempo desambiguando. Si los escribe en EARS, el equipo solo discute si los AC son correctos.

Anti-patrón: escribir AC en bullets vagos.

- AC: El usuario puede exportar
- AC: Funciona rápido
- AC: Si falla, muestra error

Patrón: escribir AC en EARS desde el primer borrador.

+ AC-1: When the user clicks "Export", the service shall generate the CSV within 5 seconds.
+ AC-2: If the export fails, then the application shall display "Export failed: {reason}" with a retry button.

Definition of Done y EARS

La Definition of Done (DoD) lista lo que debe cumplirse para considerar terminada una historia. Algunas DoD comunes:

• Todos los AC verifican (tests pasan)
• Code review aprobado
• Documentación actualizada
• Métricas de monitoreo agregadas
• Sin issues críticos en SonarQube/Lighthouse/etc

EARS facilita el primer ítem: si los AC están en EARS, hay menos discusión sobre “¿esto cuenta como terminado?”.

Epics y EARS

Las épicas describen capacidades de alto nivel. Suelen contener requisitos ubiquitous (siempre activos) que aplican a todas las historias debajo.

Épica: “Privacidad y cumplimiento GDPR”

Requisitos ubiquitous de la épica:

REQ-GDPR-001: The persistence layer shall encrypt all fields classified as "personal data" at rest.

REQ-GDPR-002: The application shall provide a "Privacy" section accessible from the user's profile menu.

REQ-GDPR-003: The system shall log all access to personal data with actor, resource, timestamp and purpose.

Las historias dentro de la épica heredan estos requisitos como contexto.

Kanban y EARS

En Kanban, las tarjetas son la unidad de trabajo. Una tarjeta típica:

TÍTULO: Permitir exportación CSV de usuarios

HISTORIA:
Como administrador, quiero exportar usuarios a CSV...

CRITERIOS DE ACEPTACIÓN:
[AC-1, AC-2, AC-3, AC-4, AC-5 en EARS]

DEFINITION OF DONE:
[checklist del proyecto]

EARS no requiere ningún cambio de proceso — encaja en cualquier formato de tarjeta.

Extreme Programming (XP) y EARS

XP prioriza tests automatizados y conversación cara a cara. EARS encaja porque:

• Los AC en EARS son la base de tests automatizados (unit, integration, e2e)
• La conversación define el “por qué”; EARS captura el “qué”
• Pair programming sobre AC ambiguos descubre defectos antes de codificar

SAFe, LeSS y escalado

En frameworks de escalado (SAFe, LeSS, Nexus), los requisitos cruzan equipos. EARS aporta:

• Lenguaje común entre equipos
• Trazabilidad vía IDs estables
• Reducción de ambigüedad al integrar entregas de múltiples teams

Spike de exploración y EARS

Un spike (investigación técnica) puede terminar con requisitos preliminares en EARS como entregable. Ejemplo:

Resultado del spike “evaluar OAuth providers”:

• REQ-AUTH-201: Where the user chooses “Sign in with Google”, when the user completes the OAuth flow, the auth service shall exchange the authorization code for an access token using the Google OAuth 2.0 endpoint.
• REQ-AUTH-202: If the OAuth provider returns an error, then the auth service shall display the provider’s error message and shall offer the user a link to retry or use a different provider.

Estimación y EARS

Las historias con criterios EARS suelen estimarse más consistentemente. Razón: hay menos varianza en lo que “estamos por construir”. El equipo no debate qué significa “validar el formulario” — el AC lo dice exacto.

Ejemplo completo: tarjeta de Jira

TÍTULO: AUTH-142 — Soportar login con MFA

HISTORIA:
Como usuario, quiero proteger mi cuenta con un segundo factor,
para reducir el riesgo si me roban la contraseña.

CRITERIOS DE ACEPTACIÓN:

AC-1: When the user enables MFA in the security settings, the auth service shall generate a TOTP secret and shall present a QR code compatible with RFC 6238.

AC-2: When the user submits a valid TOTP code during the enrollment flow, the auth service shall mark MFA as enabled for the user and shall generate 10 single-use recovery codes.

AC-3: While MFA is enabled, when the user submits valid credentials, the auth service shall require a TOTP code or recovery code before issuing a session token.

AC-4: If the user submits an invalid TOTP code 5 times within 10 minutes, then the auth service shall lock the account for 15 minutes.

AC-5: Where the user has used a recovery code, the auth service shall invalidate that recovery code and shall display the count of remaining recovery codes in the security settings.

DEFINITION OF DONE:
- [ ] AC verifican (tests automatizados pasan)
- [ ] Code review aprobado
- [ ] Métricas de login_failed agregadas a dashboard
- [ ] Documentación de soporte actualizada

Resumen

• User Stories capturan el “por qué” (valor para el usuario)
• EARS captura el “qué” (comportamiento del sistema)
• Los criterios de aceptación en EARS son directamente testeables
• Se integra con Scrum, Kanban, XP, SAFe sin fricción
• Reduce ambigüedad en refinamiento y estimación

En el siguiente capítulo vemos por qué EARS es ideal para escribir requisitos que un agente de IA puede implementar sin alucinaciones.