≡En resumen
- Una user story no es un documento: es una frase, una conversación y unos criterios de aceptación.
- Nació en Extreme Programming (Kent Beck, 1997-1999) y la popularizó Mike Cohn con su libro de 2004.
- Una épica es una historia demasiado grande; una tarea es trabajo técnico sin valor visible por sí solo.
- Un caso de uso describe la interacción completa paso a paso; la historia deja ese detalle para la conversación.
- La Guía de Scrum no obliga a usar user stories: son una práctica opcional para escribir elementos del backlog.
01 User story: definición
En 1998 Alistair Cockburn resumió su naturaleza con una frase muy citada: una historia de usuario es la promesa de una conversación. La tarjeta es un recordatorio; el conocimiento real está en lo que negocio, diseño y desarrollo hablan sobre ella y en los criterios que acuerdan para darla por buena.
Si lo que necesitas es escribirlas, con plantilla, criterios INVEST y ejemplos Given/When/Then, consulta la guía práctica sobre cómo escribir buenas user stories.
02 Origen de las historias de usuario: de Extreme Programming a Scrum
| Año | Hito | Quién |
|---|---|---|
| 1997 | Se usan historias de usuario en el proyecto C3 de Chrysler, cuna de Extreme Programming | Kent Beck |
| 1998 | «Una historia de usuario es la promesa de una conversación» | Alistair Cockburn |
| 1999 | Extreme Programming Explained incluye las historias en el juego de planificación | Kent Beck |
| 2001 | Modelo de las tres C (tarjeta, conversación, confirmación) | Ron Jeffries |
| 2001 | Plantilla «Como… quiero… para…» en el equipo XP de Connextra (Londres) | Rachel Davies y su equipo |
| 2003 | Acrónimo INVEST para evaluar historias | Bill Wake |
| 2004 | User Stories Applied se convierte en la obra de referencia | Mike Cohn |
| 2006 | Criterios de aceptación en formato Given/When/Then (BDD) | Comunidad BDD |
| 2008-2014 | Story mapping: del artículo del blog al libro User Story Mapping | Jeff Patton |
En las primeras versiones de XP la historia era una ficha de cartulina con una frase libre, y Beck la comparaba con un caso de uso más ligero. La plantilla que hoy usa casi todo el mundo llegó en 2001 desde el equipo XP de la empresa londinense Connextra: Mike Cohn atribuye la idea a Rachel Davies, que siempre la ha presentado como un trabajo de todo el equipo. Su gran aportación fue obligar a escribir el para qué.
El salto a la corriente principal llegó en 2004 con User Stories Applied, de Cohn, que sistematizó cómo escribirlas, estimarlas y planificar con ellas. Desde entonces se han añadido técnicas, pero la definición de fondo no ha cambiado: una necesidad expresada por el usuario, una conversación y una forma de comprobar que se ha resuelto.
03 Las tres C: tarjeta, conversación y confirmación
Card (tarjeta)
La frase corta, originalmente escrita en una ficha de papel. Su tamaño limitado obliga a ir al grano y evita especificaciones largas.
Conversation (conversación)
El diálogo entre quien pide y quien construye para aclarar detalles, casos límite y alternativas. Es donde se genera la mayor parte del valor.
Confirmation (confirmación)
Los criterios de aceptación y las pruebas que demuestran que la historia está hecha tal como se acordó.
Según el glosario de la Agile Alliance, una historia no es un documento: el término abarca todo el conocimiento necesario para pasar de una versión del producto a otra más valiosa. Por eso un backlog lleno de historias que nadie ha comentado es solo una lista de deseos.
04 Anatomía de una user story: qué elementos la componen
La frase «Como… quiero… para…» es solo la parte visible. En cualquier herramienta de gestión, una historia completa suele llevar varios campos más. No todos son obligatorios, pero sin los tres primeros la historia no está lista para un sprint.
Título corto
Un nombre de tres a seis palabras para encontrarla en el tablero: «Cancelar cita desde el recordatorio».
Enunciado
La frase con rol, acción y beneficio. Es el resumen de la necesidad, no su especificación.
Criterios de aceptación
Las condiciones verificables que confirman que está hecha. Son la «confirmación» de las tres C.
Notas y enlaces
Bocetos, capturas, reglas de negocio o enlaces al diseño que surgen de la conversación.
Estimación
Puntos de historia o talla relativa que el equipo asigna tras entenderla.
Prioridad y épica
Su posición en el backlog y la épica o tema al que pertenece.
05 User story vs épica vs tarea vs caso de uso
| Unidad | Qué es | Tamaño típico | Ejemplo |
|---|---|---|---|
| Tema o iniciativa | Agrupación de épicas por objetivo de negocio | Trimestres | Digitalizar la gestión de citas |
| Épica | Historia demasiado grande para un sprint; se divide | Varias semanas o meses | Como paciente, quiero gestionar mis citas online |
| User story | Necesidad de un usuario con valor visible, entregable en un sprint | De uno a varios días | Como paciente, quiero cancelar una cita desde el email de recordatorio |
| Tarea | Trabajo técnico necesario para completar una historia | Horas | Crear el endpoint de cancelación y su test |
| Caso de uso | Descripción formal de la interacción actor-sistema, con flujo principal y alternativos | Documento de una o varias páginas | CU-07 Cancelar cita: precondiciones, pasos, excepciones |
| Requisito tradicional | Enunciado de lo que el sistema debe hacer | Una línea en una especificación | El sistema permitirá cancelar citas |
06 Para qué sirve una user story (y cuándo no es la mejor herramienta)
Centra al equipo en el usuario
Cada funcionalidad se justifica por el valor que aporta a una persona, no por una idea interna.
Permite priorizar por valor
Negocio puede ordenar historias sin entender la implementación.
Facilita entregas pequeñas
Al ser verticales, cada historia terminada es software que se puede enseñar y probar.
Retrasa el detalle al último momento útil
Evitas especificar hoy lo que quizá descartes dentro de dos meses.
07 Tipos de elementos de un backlog ágil (no todo es una user story)
| Tipo | Para qué sirve | ¿Plantilla de user story? |
|---|---|---|
| User story | Funcionalidad con valor visible para un usuario | Sí: «Como… quiero… para…» |
| Historia técnica o enabler | Trabajo de arquitectura o infraestructura que habilita historias futuras | No; se describe el objetivo técnico y la historia que desbloquea |
| Spike | Investigación acotada en el tiempo para reducir incertidumbre | No; se define la pregunta a responder y el límite de tiempo |
| Bug | Defecto de algo ya entregado | No; pasos para reproducirlo, resultado esperado y obtenido |
| Requisito no funcional | Rendimiento, seguridad, accesibilidad | Mejor en la definición de hecho o como criterio de varias historias |
08 Dónde encaja la user story en un proyecto de desarrollo
-
1
Descubrimiento
Entrevistas, perfiles de usuario y objetivos de negocio generan las primeras épicas.
-
2
Mapa y MVP
Con un story mapping de Jeff Patton se ordenan por flujo y se recorta la primera versión.
-
3
Refinamiento
Las épicas prioritarias se dividen en historias con criterios de aceptación y estimación.
-
4
Sprint
El equipo las convierte en tareas, las desarrolla y las prueba.
-
5
Revisión y aprendizaje
Se enseñan funcionando y los datos de uso alimentan nuevas historias.
El paso de mapa y MVP se explica en detalle en el story mapping de Jeff Patton. Y el ciclo completo conecta con el método Lean Startup: cada historia es una hipótesis sobre lo que el usuario valora, y la entrega es el experimento que la confirma o la tumba.
Cuando decides entre comprar una herramienta o construir la tuya, las historias ayudan a comparar: si la mayoría las cubre un producto del mercado, quizá no necesitas software a medida.
En nuestros proyectos de desarrollo de software SaaS y como empresa de desarrollo de aplicaciones, las historias son el idioma común entre el cliente y el equipo: el cliente prioriza historias, no pantallas ni tecnologías.
Preguntas frecuentes sobre User story definition
Es una frase que describe lo que un usuario quiere conseguir con un producto y por qué, acompañada de criterios de aceptación. Se usa en metodologías ágiles para definir y priorizar el trabajo.
Surgieron en Extreme Programming con Kent Beck, que las usó en el proyecto C3 de Chrysler en 1997 y las describió en Extreme Programming Explained (1999). Mike Cohn las popularizó con User Stories Applied en 2004.
Una épica es una historia demasiado grande para completarse en un sprint, y se divide en varias historias más pequeñas. Ambas se escriben desde el punto de vista del usuario.
La user story es breve e informal y deja los detalles para la conversación; el caso de uso describe de forma formal toda la interacción entre actor y sistema, con flujos principales y alternativos.
No. La historia aporta valor visible al usuario; las tareas son el trabajo técnico (diseño, backend, pruebas) necesario para completarla y normalmente se miden en horas.
No. La Guía de Scrum solo habla de elementos del Product Backlog; las historias de usuario son una técnica opcional, aunque muy extendida, para redactarlos.
Fuentes consultadas
Sobre el autor
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil y artículos → Ver perfil en LinkedIn ↗