Historias de Usuario, Criterios de Aceptación y Priorización de Backlog
En el desarrollo tradicional, los requisitos se redactaban en extensos documentos técnicos de cientos de páginas que nadie leía y que quedaban obsoletos antes de programar la primera función.
En la ingeniería de software ágil, los requisitos se expresan desde la perspectiva de las necesidades reales de las personas mediante Historias de Usuario (User Stories), respaldadas por Criterios de Aceptación verificables y ordenadas mediante técnicas sistemáticas de priorización.
1. ¿Qué es una Historia de Usuario? Las Tres "C" #
Una Historia de Usuario es una descripción breve, informal y en lenguaje natural de una funcionalidad del software, redactada desde el punto de vista del usuario final o del cliente.
Ron Jeffries definió la fórmula de las Tres "C":
- Card (Tarjeta): La historia se sintetiza en una tarjeta física o ticket digital (Jira/Linear).
- Conversation (Conversación): La tarjeta es una promesa de conversación continua entre el Product Owner, los desarrolladores y los usuarios para clarificar detalles técnicos.
- Confirmation (Confirmación): Los criterios de aceptación formales que determinan cuándo la historia está completada con éxito.
1PLANTILLA ESTÁNDAR DE UNA HISTORIA DE USUARIO 2┌─────────────────────────────────────────────────────────────────────────────┐ 3│ COMO [Rol o tipo de usuario específico] │ 4│ QUIERO [Capacidad, acción o comportamiento que desea realizar] │ 5│ PARA [Beneficio, valor o meta de negocio que se desea alcanzar] │ 6└─────────────────────────────────────────────────────────────────────────────┘
Ejemplo:
"Como cliente registrado en la tienda online, quiero guardar artículos en una lista de favoritos, para poder comprarlos más tarde sin tener que buscarlos de nuevo."
2. El Modelo INVEST para Historias de Calidad #
Para validar que una historia de usuario está lista para entrar en un Sprint (Definition of Ready), se evalúan los criterios INVEST (creados por Bill Wake):
| Letra | Criterio INVEST | Significado Práctico en Software |
|---|---|---|
| I | Independent (Independiente) | La historia no debe tener dependencias cruzadas rígidas con otras historias del sprint. |
| N | Negotiable (Negociable) | No es un contrato cerrado; los detalles de implementación se debaten con el equipo. |
| V | Valuable (Valiosa) | Aporta un beneficio observable al usuario final o a la estrategia de negocio. |
| E | Estimable (Estimable) | El equipo técnico comprende el alcance suficiente para estimarla en Story Points. |
| S | Small (Pequeña) | Su tamaño es adecuado para completarse con holgura dentro de un único Sprint (1-2 semanas). |
| T | Testable (Verificable) | Cuenta con criterios de aceptación objetivos que permiten escribir pruebas automatizadas. |
3. Criterios de Aceptación y el Formato BDD / Gherkin #
Los Criterios de Aceptación delimitan la frontera de la funcionalidad. En la actualidad se redactan habitualmente mediante el lenguaje Gherkin (del enfoque Behavior-Driven Development - BDD):
1Escenario: Intento de inicio de sesión con contraseña incorrecta 2 Dado que el usuario "carlos@empresa.com" está registrado y activo 3 Cuando introduce su correo y una contraseña errónea 4 Y pulsa el botón "Iniciar Sesión" 5 Entonces el sistema muestra el mensaje de error "Credenciales no válidas" 6 Y el contador de intentos fallidos se incrementa en 1 7 Y el usuario permanece en la pantalla de login sin generar token JWT
4. Técnicas de Priorización del Product Backlog #
El Product Owner no puede ordenar el backlog por intuición personal; utiliza marcos de priorización analíticos:
1MATRIZ VALOR VS ESFUERZO (QUICK WINS) 2 ALTO │ 🎯 Victorias Rápidas (Quick Wins) │ 🚀 Proyectos Estratégicos 3 │ (Hacer de inmediato) │ (Planificar y dividir) 4 VALOR ├────────────────────────────────────┼─────────────────────────── 5 NEGOCIO │ 🗑️ Descartar / Tareas Residuales │ ⏳ Agujeros Negros (Evitar) 6 BAJO │ (Hacer solo si sobra tiempo) │ (Alto esfuerzo / Poco valor) 7 └────────────────────────────────────┴─────────────────────────── 8 BAJO ALTO 9 ESFUERZO / COSTE
El Método MoSCoW: #
- M - Must have (Obligatorio): Requisitos no negociables sin los cuales el software no puede funcionar ni lanzarse a producción.
- S - Should have (Debería tener): Funcionalidades de alto valor pero con alternativas temporales si hay presión de tiempo.
- C - Could have (Podría tener): Mejoras deseables que solo se incluirán si el equipo termina antes el trabajo principal.
- W - Won't have (No se incluirá ahora): Requisitos explícitamente descartados para la versión o release actual.
WSJF (Weighted Shortest Job First): #
Prioriza las tareas calculando el Coste del Retraso (Cost of Delay) dividido entre la duración o tamaño de la tarea:
Las tareas cortas de altísimo valor obtienen la puntuación más alta y se programan primero.
5. Caso Práctico: Descomposición de una Épica #
Imagina una Épica grande: "Módulo de Pagos de la App":
- Es demasiado grande para un sprint (viola la S de Small en INVEST).
- Se descompone en 3 historias de usuario independientes:
- Historia 1 (Must): Pago con tarjeta de crédito mediante Stripe SDK.
- Historia 2 (Should): Pago rápido con Apple Pay y Google Pay.
- Historia 3 (Could): Generación y envío automático de factura en PDF por email.
Resumen del tema
Conceptos clave #
- Estructura de Historias de Usuario: fórmula Como [rol], Quiero [acción], Para [beneficio] complementada con las 3 Cs (Card, Conversation, Confirmation).
- Criterios INVEST: Independent, Negotiable, Valuable, Estimable, Small y Testable.
- Formato Gherkin (BDD): estructura Dado [contexto], Cuando [evento], Entonces [resultado observable] para definir criterios de aceptación automatizables.
- Métodos de Priorización: MoSCoW (Must, Should, Could, Won't), Matriz Valor vs Esfuerzo y WSJF (Coste del Retraso / Tamaño).
Qué debes recordar #
Las historias de usuario son instrumentos de conversación continua; redactarlas siguiendo INVEST y priorizarlas con MoSCoW garantiza entregar el máximo valor de negocio en cada sprint.