≡En resumen
- Una user story describe un resultado para una persona concreta, no una tarea técnica ni una pantalla.
- La plantilla «Como… quiero… para…» obliga a explicitar quién, qué y, sobre todo, por qué.
- INVEST es la lista de control: independiente, negociable, valiosa, estimable, pequeña y testable.
- Sin criterios de aceptación la historia está incompleta; Given/When/Then los convierte en casos de prueba.
- Las historias grandes (épicas) se dividen por pasos del flujo, reglas de negocio o variantes de datos, nunca por capas técnicas.
01 ¿Qué son las user stories o historias de usuario?
Esta ficha es práctica: cómo escribirlas, validarlas y dividirlas. Si buscas el concepto, su origen en Extreme Programming y cómo se diferencia de una épica, una tarea o un caso de uso, lo tienes en qué es una user story y de dónde viene.
La idea clave es que la historia no es un documento cerrado. Ron Jeffries lo resumió en 2001 con las tres C: una tarjeta (card) con la frase, una conversación entre negocio, diseño y desarrollo para aclarar detalles, y una confirmación en forma de criterios de aceptación.
02 La plantilla «Como… quiero… para…» y cómo rellenarla
| Parte | Pregunta que responde | Mal escrito | Bien escrito |
|---|---|---|---|
| Como [rol] | ¿Quién lo necesita? | Como usuario | Como paciente que reserva por primera vez |
| quiero [acción] | ¿Qué quiere hacer? | quiero un calendario con filtros en React | quiero ver los huecos libres de mi fisioterapeuta esta semana |
| para [beneficio] | ¿Para qué? ¿Qué gana? | para usar la app | para reservar sin tener que llamar a la clínica |
La parte que más se omite es el «para». Es la más importante: explica el objetivo y abre la puerta a soluciones mejores que la pedida. «Quiero exportar a Excel» puede esconder «para enviar el informe mensual a mi gerente», y quizá un envío automático por email resuelva lo mismo con menos trabajo.
03 Criterios INVEST: cómo saber si una user story está bien escrita
Bill Wake publicó el acrónimo INVEST el 17 de agosto de 2003 en su artículo «INVEST in Good Stories, and SMART Tasks». Son seis cualidades que conviene revisar antes de meter una historia en un sprint.
| Letra | Significado | Pregunta de control |
|---|---|---|
| I | Independent (independiente) | ¿Se puede desarrollar y entregar sin esperar a otra historia? |
| N | Negotiable (negociable) | ¿Deja margen para acordar el cómo, o ya es una especificación cerrada? |
| V | Valuable (valiosa) | ¿Aporta algo que el usuario o el negocio notan por sí solo? |
| E | Estimable | ¿El equipo entiende lo suficiente para estimar el esfuerzo? |
| S | Small (pequeña) | ¿Cabe con holgura en un sprint? |
| T | Testable | ¿Se puede escribir una prueba que diga si está hecha? |
04 Criterios de aceptación con Given/When/Then
Los criterios de aceptación son las condiciones concretas que debe cumplir la historia para darse por terminada. El formato Given/When/Then (Dado/Cuando/Entonces) se popularizó en 2006 con el desarrollo guiado por comportamiento (BDD) y tiene una ventaja: cada criterio se puede automatizar como prueba casi sin traducción.
Historia: Como paciente que reserva por primera vez, quiero ver los huecos libres de mi fisioterapeuta esta semana para reservar sin llamar a la clínica.
- Escenario 1.
Dadoque mi fisioterapeuta tiene huecos libres esta semana,cuandoabro su ficha,entoncesveo los huecos agrupados por día y en mi zona horaria. - Escenario 2.
Dadoque no tiene huecos esta semana,cuandoabro su ficha,entoncesveo el primer hueco disponible y un botón para avisarme si se libera uno antes. - Escenario 3.
Dadoque otro paciente reserva un hueco mientras lo miro,cuandointento reservarlo,entoncesveo un aviso y la lista actualizada.
05 Ejemplos de user stories para una web, una app o un SaaS
Tienda online
Como comprador que vuelve, quiero repetir un pedido anterior con un clic para no buscar otra vez los mismos productos.
App de reservas
Como cliente de un centro deportivo, quiero recibir un aviso si se libera plaza en una clase llena para no perder la oportunidad.
SaaS B2B
Como responsable de facturación, quiero invitar a mi gestor con permisos de solo lectura para que descargue las facturas sin acceder al resto.
Web corporativa
Como visitante que compara proveedores, quiero ver precios orientativos por servicio para saber si encajo antes de pedir presupuesto.
Área privada
Como usuario que ha olvidado la contraseña, quiero recuperarla desde el móvil en menos de un minuto para no abandonar la compra.
Panel interno
Como administrador de la clínica, quiero bloquear una franja de agenda por vacaciones para que nadie reserve en esos días.
Fíjate en que ninguna menciona tecnologías ni componentes. Cuando un equipo de desarrollo de apps a medida recibe historias así, puede proponer la solución más sencilla que cumpla el beneficio, y el cliente puede priorizar con criterio de negocio.
06 Cómo dividir historias grandes (épicas) en historias pequeñas
Una historia que no cabe en un sprint es una épica. Dividirla bien es la habilidad que más distingue a un buen product owner. La regla: cada trozo debe seguir aportando valor visible, aunque sea menor.
-
1
Por pasos del flujo
«Comprar» se divide en buscar, añadir al carrito, pagar y recibir confirmación. Un mapa de historias ayuda a verlos todos.
-
2
Por reglas de negocio
Primero envío gratuito a península; después, Baleares y Canarias con sus tarifas.
-
3
Por variantes de datos
Pago con tarjeta primero; Bizum y transferencia en historias posteriores.
-
4
Camino feliz primero
El flujo sin errores en una historia; los casos límite (tarjeta rechazada, stock agotado) en otras.
-
5
Por plataforma
Web primero; app iOS y Android después, si el negocio lo permite.
-
6
Spike si hay incertidumbre
Si no sabes cuánto cuesta integrar una API, una investigación acotada en el tiempo (spike) precede a la historia.
Cuando el backlog pasa de unas decenas de historias, una lista plana deja de funcionar. El mapa de historias de usuario las ordena por flujo y prioridad y permite recortar la primera versión, el producto mínimo viable, sin dejar huecos en el recorrido del usuario.
07 Errores frecuentes al escribir user stories
- ✓Escribir tareas técnicas con la plantilla: «Como desarrollador, quiero migrar la base de datos…» no es una historia de usuario.
- ✓Omitir el «para», con lo que nadie puede cuestionar si la solución pedida es la mejor.
- ✓Describir la interfaz en la historia (colores, botones, desplegables) en lugar del objetivo.
- ✓Historias sin criterios de aceptación, que acaban en discusiones sobre si están terminadas.
- ✓Épicas disfrazadas de historias que nunca se cierran en un sprint.
- ✓Escribirlas solo el product owner, sin la conversación con diseño y desarrollo.
- ✓No validar con usuarios reales: una historia bien escrita puede resolver un problema que nadie tiene.
08 Cómo usar las user stories en tu proyecto
-
1
Taller inicial
Negocio, diseño y desarrollo escriben juntos las historias de alto nivel a partir de los perfiles de usuario y sus objetivos.
-
2
Backlog priorizado
Se ordenan por valor, riesgo y dependencia. Las de arriba se detallan; las de abajo pueden seguir siendo épicas.
-
3
Refinamiento
Antes de cada sprint se añaden criterios de aceptación, se dividen las grandes y se estiman (puntos de historia o tallas).
-
4
Sprint y demo
El equipo las desarrolla y, en la revisión, se comprueban contra sus criterios delante del cliente.
-
5
Aprendizaje
Con datos de uso reales, se reescriben o se descartan historias del backlog.
En un proyecto de desarrollo de aplicaciones web a medida, este ciclo te permite ver software funcionando cada dos o tres semanas y cambiar prioridades sin renegociar un documento de requisitos de cien páginas. Pide que cada historia terminada se enseñe funcionando en la demo: es la mejor forma de comprobar que lo que pagas se corresponde con lo que se entrega.
Preguntas frecuentes sobre User stories
User story significa historia de usuario: una descripción breve de una funcionalidad contada desde el punto de vista de quien la necesita, con el formato «Como [rol], quiero [acción] para [beneficio]» y unos criterios de aceptación.
Se escribe identificando un rol concreto, la acción que quiere realizar y el beneficio que obtiene, y se completa con criterios de aceptación, idealmente en formato Dado/Cuando/Entonces. Después se revisa con la lista INVEST.
Normalmente las escribe o coordina el product owner, pero las buenas historias salen de la conversación con diseño, desarrollo y, cuando es posible, con usuarios reales. Cualquier miembro del equipo puede proponerlas.
No hay un número fijo; lo habitual son entre tres y siete. Si necesitas muchos más, probablemente la historia es demasiado grande y conviene dividirla.
Un requisito tradicional describe qué debe hacer el sistema; una user story describe qué quiere conseguir una persona y por qué, y deja el detalle para la conversación. La historia se centra en el valor, no en la especificación.
Lo más común es estimarlas en puntos de historia con planning poker o por tallas de camiseta (S, M, L). Lo importante es comparar historias entre sí, no convertirlas en horas exactas.
Jira, Linear, Azure DevOps, Trello o GitHub Projects son habituales. Para empezar basta un tablero con tarjetas; la herramienta importa menos que la calidad de las historias.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗