7 min lectura • Guide 269 of 877
Escribiendo User Stories Efectivas
Las user stories no son documentos de requisitos—son marcadores de posición para conversaciones. Una buena user story captura quién necesita qué y por qué, es suficientemente pequeña para completar en un sprint e invita a la discusión sobre los detalles. Esta guía cubre cómo escribir stories que realmente ayuden a los equipos a construir lo correcto.
Elementos de la Story
| Elemento | Propósito | Ejemplo |
|---|---|---|
| Rol de Usuario | Quién se beneficia | "Como cliente..." |
| Meta | Qué quieren | "...quiero guardar mi carrito..." |
| Beneficio | Por qué importa | "...para volver después" |
| Criterios | Definición de done | "El carrito persiste 30 días" |
Formato de Story
El Template Clásico
TEMPLATE DE USER STORY
══════════════════════
FORMATO:
─────────────────────────────────────
Como [tipo de usuario]
Quiero [funcionalidad/meta]
Para que [beneficio/razón]
CRITERIOS DE ACEPTACIÓN:
─────────────────────────────────────
☐ Criterio 1
☐ Criterio 2
☐ Criterio 3
EJEMPLO COMPLETO:
─────────────────────────────────────
Como cliente frecuente
Quiero guardar productos en mi carrito
Para que pueda continuar mi compra más tarde
Criterios de Aceptación:
☐ Carrito se guarda automáticamente
☐ Carrito persiste por 30 días
☐ Usuario ve carrito guardado al volver
☐ Funciona sin necesidad de login
Principio INVEST
CHECKLIST INVEST
════════════════
I - INDEPENDIENTE
┌─────────────────────────────────────────────────────────────┐
│ La story puede completarse sin depender de otras stories │
│ │
│ ✅ BUENO: "Como usuario, puedo filtrar productos" │
│ ❌ MALO: "Después de que el login esté listo..." │
└─────────────────────────────────────────────────────────────┘
N - NEGOCIABLE
┌─────────────────────────────────────────────────────────────┐
│ Los detalles pueden discutirse y ajustarse │
│ │
│ ✅ BUENO: "Exportar reportes en formato descargable" │
│ ❌ MALO: "Botón azul de 32px en esquina superior derecha" │
└─────────────────────────────────────────────────────────────┘
V - VALIOSA
┌─────────────────────────────────────────────────────────────┐
│ Entrega valor claro al usuario o negocio │
│ │
│ ✅ BUENO: "Buscar productos por categoría" │
│ ❌ MALO: "Refactorizar clase DatabaseHelper" │
└─────────────────────────────────────────────────────────────┘
E - ESTIMABLE
┌─────────────────────────────────────────────────────────────┐
│ El equipo puede estimar el esfuerzo requerido │
│ │
│ ✅ BUENO: Story clara con criterios definidos │
│ ❌ MALO: "Mejorar el sistema" (sin detalles) │
└─────────────────────────────────────────────────────────────┘
S - PEQUEÑA (Small)
┌─────────────────────────────────────────────────────────────┐
│ Cabe cómodamente en un sprint │
│ │
│ ✅ BUENO: 1-5 story points, pocos días de trabajo │
│ ❌ MALO: Epic sin dividir que tomaría semanas │
└─────────────────────────────────────────────────────────────┘
T - TESTEABLE
┌─────────────────────────────────────────────────────────────┐
│ Se puede verificar objetivamente si está completa │
│ │
│ ✅ BUENO: "Usuario recibe email de confirmación" │
│ ❌ MALO: "Sistema debe ser amigable" │
└─────────────────────────────────────────────────────────────┘
Escribiendo Criterios de Aceptación
FORMATOS DE CRITERIOS
═════════════════════
FORMATO 1: CHECKLIST
┌─────────────────────────────────────────────────────────────┐
│ Criterios de Aceptación: │
│ ☐ Usuario puede hacer X │
│ ☐ Sistema responde con Y │
│ ☐ Error Z se muestra si condición inválida │
└─────────────────────────────────────────────────────────────┘
FORMATO 2: GIVEN-WHEN-THEN
┌─────────────────────────────────────────────────────────────┐
│ Escenario: Búsqueda exitosa │
│ │
│ DADO: Usuario en página de búsqueda │
│ CUANDO: Ingresa término y hace clic en buscar │
│ ENTONCES: Ve lista de resultados relevantes │
│ Y: Resultados muestran nombre, precio e imagen │
└─────────────────────────────────────────────────────────────┘
CUÁL USAR:
┌─────────────────────────────────────────────────────────────┐
│ Checklist: Para stories simples y directas │
│ Given-When-Then: Para comportamientos y flujos complejos │
└─────────────────────────────────────────────────────────────┘
Errores Comunes
ANTI-PATRONES DE USER STORIES
═════════════════════════════
❌ DEMASIADO TÉCNICA:
┌─────────────────────────────────────────────────────────────┐
│ "Como desarrollador, quiero migrar a PostgreSQL 15" │
│ │
│ PROBLEMA: No expresa valor para el usuario │
│ │
│ ✅ MEJOR: │
│ "Como usuario, quiero que las búsquedas sean más rápidas │
│ para que pueda encontrar productos sin esperar" │
│ (Nota técnica: requiere migración de BD) │
└─────────────────────────────────────────────────────────────┘
❌ SIN BENEFICIO:
┌─────────────────────────────────────────────────────────────┐
│ "Como usuario, quiero un botón de exportar" │
│ │
│ PROBLEMA: No explica el para qué │
│ │
│ ✅ MEJOR: │
│ "Como usuario, quiero exportar mis datos │
│ para que pueda analizarlos en Excel" │
└─────────────────────────────────────────────────────────────┘
❌ DEMASIADO VAGA:
┌─────────────────────────────────────────────────────────────┐
│ "Como usuario, quiero una mejor experiencia" │
│ │
│ PROBLEMA: No es medible ni actionable │
│ │
│ ✅ MEJOR: │
│ "Como usuario, quiero que el checkout tome menos de │
│ 3 clics para que pueda comprar más rápido" │
└─────────────────────────────────────────────────────────────┘
❌ DEMASIADO GRANDE:
┌─────────────────────────────────────────────────────────────┐
│ "Como usuario, quiero un sistema de reportes completo" │
│ │
│ PROBLEMA: Epic disfrazado de story │
│ │
│ ✅ MEJOR: Dividir en stories pequeñas │
│ - "Ver reporte de ventas mensual" │
│ - "Exportar reporte a PDF" │
│ - "Filtrar reporte por categoría" │
└─────────────────────────────────────────────────────────────┘
Dividiendo Stories
TÉCNICAS DE DIVISIÓN
════════════════════
POR FLUJO DE TRABAJO:
┌─────────────────────────────────────────────────────────────┐
│ EPIC: Proceso de checkout │
│ │ │
│ ├── Story: Ver resumen del carrito │
│ ├── Story: Ingresar dirección de envío │
│ ├── Story: Seleccionar método de pago │
│ ├── Story: Confirmar pedido │
│ └── Story: Recibir confirmación por email │
└─────────────────────────────────────────────────────────────┘
POR DATOS/PARÁMETROS:
┌─────────────────────────────────────────────────────────────┐
│ EPIC: Buscar productos │
│ │ │
│ ├── Story: Buscar por nombre │
│ ├── Story: Filtrar por categoría │
│ ├── Story: Filtrar por precio │
│ └── Story: Ordenar resultados │
└─────────────────────────────────────────────────────────────┘
POR OPERACIONES CRUD:
┌─────────────────────────────────────────────────────────────┐
│ EPIC: Gestionar perfil │
│ │ │
│ ├── Story: Ver mi perfil │
│ ├── Story: Editar información básica │
│ ├── Story: Cambiar contraseña │
│ └── Story: Eliminar mi cuenta │
└─────────────────────────────────────────────────────────────┘
Proceso de Refinamiento
REFINAMIENTO DE STORIES
═══════════════════════
ANTES DE REFINAMIENTO:
┌─────────────────────────────────────────────────────────────┐
│ Story vaga: "Sistema de notificaciones" │
└─────────────────────────────────────────────────────────────┘
│
▼
PASO 1: DEFINIR USUARIO Y BENEFICIO
┌─────────────────────────────────────────────────────────────┐
│ ¿Quién? Project Managers │
│ ¿Por qué? Saber cuando tareas cambian de estado │
└─────────────────────────────────────────────────────────────┘
│
▼
PASO 2: ESCRIBIR FORMATO COMPLETO
┌─────────────────────────────────────────────────────────────┐
│ Como Project Manager │
│ Quiero recibir notificaciones cuando tareas cambian │
│ Para que pueda mantenerme al tanto sin revisar el board │
└─────────────────────────────────────────────────────────────┘
│
▼
PASO 3: AGREGAR CRITERIOS
┌─────────────────────────────────────────────────────────────┐
│ ☐ Notificación cuando tarea asignada a mí cambia │
│ ☐ Notificación llega en menos de 30 segundos │
│ ☐ Puedo configurar qué tipos de cambios notificar │
│ ☐ Notificaciones aparecen en app y email │
└─────────────────────────────────────────────────────────────┘
│
▼
PASO 4: VALIDAR CON EQUIPO
┌─────────────────────────────────────────────────────────────┐
│ ✅ ¿Es INVEST? │
│ ✅ ¿Equipo puede estimarla? │
│ ✅ ¿Todos entienden lo mismo? │
└─────────────────────────────────────────────────────────────┘
Templates en GitScrum
CONFIGURAR TEMPLATE DE STORY EN GITSCRUM
════════════════════════════════════════
┌─────────────────────────────────────────────────────────────┐
│ ## User Story │
│ │
│ **Como** [tipo de usuario] │
│ **Quiero** [funcionalidad] │
│ **Para que** [beneficio] │
│ │
│ ## Criterios de Aceptación │
│ - [ ] Criterio 1 │
│ - [ ] Criterio 2 │
│ - [ ] Criterio 3 │
│ │
│ ## Notas Adicionales │
│ [Mockups, consideraciones técnicas, dependencias] │
│ │
│ ## Definición de Done │
│ - [ ] Código revisado │
│ - [ ] Tests pasando │
│ - [ ] Documentación actualizada │
│ - [ ] Desplegado a staging │
└─────────────────────────────────────────────────────────────┘
Checklist de Calidad
ANTES DE AGREGAR AL SPRINT
══════════════════════════
☐ ¿Sigue formato "Como... Quiero... Para que..."?
☐ ¿Tiene criterios de aceptación claros?
☐ ¿Es independiente de otras stories?
☐ ¿Entrega valor al usuario?
☐ ¿El equipo puede estimarla?
☐ ¿Cabe en un sprint (1-5 puntos)?
☐ ¿Es testeable objetivamente?
☐ ¿El equipo entiende lo mismo?