9 min lectura • Guide 788 of 877
Mejores Prácticas de Escritura de User Stories
Las user stories bien escritas alinean equipos y reducen la ambigüedad. GitScrum proporciona campos para historias, criterios de aceptación, story points y etiquetas para categorización.
Plantilla de User Story
Formato Estándar
FORMATO DE USER STORY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PLANTILLA CLÁSICA: │
│ ─────────────────── │
│ │
│ Como [tipo de usuario], │
│ Quiero [acción/capacidad], │
│ Para que [beneficio/valor]. │
│ │
│ EJEMPLO: │
│ ───────── │
│ Como manager de equipo, │
│ Quiero ver el progreso del sprint de mi equipo, │
│ Para que pueda identificar bloqueadores temprano. │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DESGLOSE: │
│ │
│ "Como [tipo de usuario]" │
│ • ¿Quién se beneficia? │
│ • Sé específico (no "usuario") │
│ • Usa personas si están definidas │
│ │
│ "Quiero [acción/capacidad]" │
│ • ¿Qué pueden hacer? │
│ • Resultado observable │
│ • No detalles de implementación │
│ │
│ "Para que [beneficio/valor]" │
│ • ¿Por qué importa? │
│ • Objetivo de negocio │
│ • Impulsa priorización │
└─────────────────────────────────────────────────────────────┘
Lista de Verificación INVEST
Los Seis Criterios
CRITERIOS INVEST:
┌─────────────────────────────────────────────────────────────┐
│ │
│ I - INDEPENDIENTE │
│ ───────────────── │
│ ✅ Puede desarrollarse sin otras historias │
│ ✅ Sin dependencias duras de bloqueo │
│ ✅ Orden de desarrollo flexible │
│ │
│ ❌ "Después de completar el login de usuario..." │
│ ✅ "Como usuario logueado, puedo..." │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ N - NEGOCIABLE │
│ ──────────────── │
│ ✅ Los detalles pueden discutirse │
│ ✅ La implementación es flexible │
│ ✅ Invita a conversación │
│ │
│ ❌ "Usar dropdown con exactamente 5 opciones" │
│ ✅ "Permitir filtrar por categoría" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ V - VALIOSA │
│ ──────────────── │
│ ✅ Entrega beneficio a usuarios o negocio │
│ ✅ No solo trabajo técnico │
│ ✅ Justificación clara de "por qué" │
│ │
│ ❌ "Configurar conexión de base de datos" │
│ ✅ "Guardar preferencias de usuario entre sesiones" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ E - ESTIMABLE │
│ ────────────── │
│ ✅ El equipo puede dimensionarla │
│ ✅ Alcance claro suficiente │
│ ✅ No muy vaga │
│ │
│ ❌ "Mejorar rendimiento" │
│ ✅ "Reducir tiempo de carga de dashboard a <2 segundos" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ S - PEQUEÑA │
│ ──────────── │
│ ✅ Cabe en un sprint │
│ ✅ 1-8 story points idealmente │
│ ✅ Se puede completar en días, no semanas │
│ │
│ ❌ 13+ puntos - dividir necesario │
│ ✅ 3-5 puntos - tamaño ideal │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ T - TESTEABLE │
│ ────────────── │
│ ✅ Criterios de aceptación claros │
│ ✅ Se puede verificar que funciona │
│ ✅ Definición de done demostrable │
│ │
│ ❌ "Hacer la experiencia mejor" │
│ ✅ "Los usuarios pueden completar checkout en <3 clics" │
└─────────────────────────────────────────────────────────────┘
Criterios de Aceptación
Formato Given-When-Then
ESCRIBIENDO CRITERIOS DE ACEPTACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PLANTILLA GIVEN-WHEN-THEN: │
│ ────────────────────────── │
│ │
│ Given (Dado) [contexto/precondición] │
│ When (Cuando) [acción/trigger] │
│ Then (Entonces) [resultado esperado] │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EJEMPLO: Feature de Login │
│ │
│ Historia: │
│ Como usuario registrado, │
│ Quiero hacer login con mi email y contraseña, │
│ Para que pueda acceder a mi cuenta. │
│ │
│ Criterios de Aceptación: │
│ │
│ AC1: Login exitoso │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Given estoy en la página de login ││
│ │ When ingreso credenciales válidas ││
│ │ Then soy redirigido a mi dashboard ││
│ │ And veo un mensaje de bienvenida ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AC2: Contraseña inválida │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Given estoy en la página de login ││
│ │ When ingreso email válido pero contraseña incorrecta ││
│ │ Then veo mensaje de error ││
│ │ And permanezco en la página de login ││
│ │ And el campo de contraseña está limpio ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AC3: Email no encontrado │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Given estoy en la página de login ││
│ │ When ingreso un email no registrado ││
│ │ Then veo mensaje "Email no encontrado" ││
│ │ And el enlace de registro es visible ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AC4: Bloqueo de cuenta │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Given he fallado el login 5 veces ││
│ │ When intento login de nuevo ││
│ │ Then veo mensaje de cuenta bloqueada ││
│ │ And el email de recuperación es enviado ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas de AC
HACIENDO AC EFECTIVOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BUENAS PRÁCTICAS: │
│ ────────────────── │
│ │
│ ✅ Enfocarse en comportamiento, no implementación │
│ ❌ "Al hacer clic, hacer llamada AJAX" │
│ ✅ "Al hacer clic, los resultados se actualizan" │
│ │
│ ✅ Incluir happy path y casos edge │
│ • ¿Qué si el input está vacío? │
│ • ¿Qué si la red falla? │
│ • ¿Qué si el usuario no tiene permiso? │
│ │
│ ✅ Ser específico y medible │
│ ❌ "La carga debería ser rápida" │
│ ✅ "La página carga en menos de 2 segundos" │
│ │
│ ✅ Mantenerlo conciso │
│ • 3-7 criterios por historia │
│ • Si más, considerar dividir historia │
│ │
│ ✅ Hacerlo testeable │
│ • QA puede verificar cada AC │
│ • Automatizable donde sea posible │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EVITAR: │
│ ──────── │
│ │
│ ❌ Detalles de implementación │
│ "Usar componente DatePicker de terceros" │
│ │
│ ❌ Términos vagos │
│ "Debería ser amigable con el usuario" │
│ │
│ ❌ Demasiados ACs │
│ 15+ criterios = historia muy grande │
│ │
│ ❌ Suposiciones no establecidas │
│ Establecer precondiciones claramente │
└─────────────────────────────────────────────────────────────┘
Tipos de Historia
Feature vs Bug vs Technical
TIPOS DE USER STORY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ HISTORIA DE FEATURE: │
│ ───────────────────── │
│ Nueva capacidad para usuarios │
│ │
│ "Como [usuario], quiero [nueva capacidad] para [valor]" │
│ │
│ Ejemplo: │
│ Como manager de equipo, │
│ Quiero exportar datos del sprint a PDF, │
│ Para que pueda compartir el progreso con stakeholders. │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ HISTORIA DE BUG-FIX: │
│ ───────────────────── │
│ Arreglar comportamiento roto │
│ │
│ "Como [usuario], necesito [fix] para que [pueda funcionar]"│
│ │
│ Ejemplo: │
│ Como usuario, │
│ Necesito que el formulario de login funcione en Safari, │
│ Para que pueda acceder a mi cuenta desde Mac. │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ HISTORIA TÉCNICA: │
│ ─────────────────── │
│ Trabajo de infraestructura con impacto en usuario │
│ │
│ "Para que [beneficio de usuario], necesitamos [trabajo]" │
│ │
│ Ejemplo: │
│ Para que los usuarios experimenten tiempos de carga │
│ más rápidos, necesitamos implementar caching. │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPIKE (INVESTIGACIÓN): │
│ ─────────────────────── │
│ Investigación para reducir incertidumbre │
│ │
│ "Investigar [tema] para determinar [decisión]" │
│ │
│ Ejemplo: │
│ Investigar opciones de gateway de pagos para │
│ determinar cuál soporta nuestra expansión global. │
│ │
│ Timebox: máximo 1-2 días │
│ Salida: Decisión o más historias │
└─────────────────────────────────────────────────────────────┘
Errores Comunes
Qué Evitar
ANTIPATRONES DE USER STORY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ❌ HISTORIA ÉPICA DISFRAZADA: │
│ │
│ "Como usuario, quiero gestionar mis datos" │
│ │
│ → Muy vago, muy grande │
│ → Dividir en historias específicas │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ❌ TAREA TÉCNICA COMO HISTORIA: │
│ │
│ "Como desarrollador, quiero refactorizar el módulo auth" │
│ │
│ → El desarrollador no es un usuario │
│ → Expresar beneficio de usuario │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ❌ DISEÑO DE UI EN HISTORIA: │
│ │
│ "Como usuario, quiero un botón azul en la esquina │
│ superior derecha que diga 'Guardar'" │
│ │
│ → Demasiado prescriptivo │
│ → Expresar necesidad, no solución │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ❌ FALTA "PARA QUE": │
│ │
│ "Como admin, quiero ver una lista de usuarios" │
│ │
│ → ¿Por qué? ¿Cuál es el valor? │
│ → Agregar justificación de negocio │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ❌ "USUARIO" GENÉRICO: │
│ │
│ "Como usuario, quiero..." │
│ │
│ → ¿Qué tipo de usuario? │
│ → Usar personas específicas │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ❌ MÚLTIPLES FEATURES EN UNA: │
│ │
│ "Como usuario, quiero buscar, filtrar y ordenar items │
│ y exportarlos a CSV" │
│ │
│ → Dividir en historias separadas │
│ → Una capacidad por historia │
└─────────────────────────────────────────────────────────────┘