Historia de usuario
Una historia de usuario es una descripción breve de una funcionalidad que debe incorporar un sistema, escrita desde la perspectiva de quien la necesita, cuya implementación aporta valor al cliente o al usuario. Es la unidad de trabajo central de la pila del producto en Scrum y la forma más habitual de expresar requisitos ágiles.
A diferencia de los documentos de especificación tradicionales, la historia de usuario no es un contrato cerrado: es un punto de partida para la conversación. Ron Jeffries describió esta idea con las tres Cs: Card (tarjeta), Conversation (conversación) y Confirmation (confirmación). La tarjeta es el soporte físico o digital; la conversación es el diálogo entre el equipo y el propietario del producto que aporta el contexto real; y la confirmación son los criterios de aceptación que determinan cuándo la historia está terminada.
Estructura
La estructura de una historia de usuario incluye:
- Nombre: breve y descriptivo. Se usa como referencia en la pila del producto y en las conversaciones del equipo.
- Descripción: expresada habitualmente con la fórmula Como [tipo de usuario], quiero [funcionalidad], para [beneficio]. Describe quién necesita la funcionalidad, qué necesita y para qué.
- Criterios de aceptación: condiciones que deben cumplirse para que el propietario del producto considere la historia terminada y aceptable.
- Información adicional: prioridad, riesgo, estimación de tamaño u otros campos que el equipo necesite para gestionar la pila.
El formato Como / Quiero / Para
El formato más extendido para escribir la descripción de una historia sigue esta plantilla:
'Como' [tipo de usuario], quiero [acción o funcionalidad], para [beneficio o resultado].
Ejemplo: Como cliente registrado, quiero recuperar mi contraseña por email, para poder acceder a mi cuenta si la olvido.
La parte para es la más importante y la más frecuentemente omitida: expresar el beneficio obliga a quien escribe la historia a pensar en el valor real que aporta, no solo en la funcionalidad técnica.
Las seis características INVEST
El método INVEST fue formulado por Bill Wake en 2003 y popularizado por Mike Cohn en User Stories Applied (2004). Sirve para comprobar la calidad de una historia revisando que cumpla seis características:
- I — Independent (Independiente): planificable e implementable en cualquier orden. Las dependencias entre historias deben reducirse combinando o dividiendo.
- N — Negotiable (Negociable): es una descripción abierta, no un contrato cerrado. Los detalles se acuerdan en la conversación; la historia no debe imponer el cómo.
- V — Valuable (Valiosa): aporta valor al cliente o al usuario. Una buena práctica es que sean ellos quienes la escriban o la validen.
- E — Estimable (Estimable): el equipo puede asignarle un tamaño con suficiente precisión para priorizarla. Si no puede estimarse, suele indicar que está mal definida o que el equipo carece del conocimiento necesario.
- S — Small (Pequeña): realizable en pocas semanas por una persona, idealmente en días. Una descripción corta ayuda a mantener el tamaño controlado.
- T — Testable (Comprobable): tiene criterios de aceptación claros. Si no puede probarse, o no está suficientemente clara, o no es lo suficientemente valiosa.
De temas y épicas a tareas
Las historias de usuario se organizan en niveles de granularidad:
- Tema: agrupación de épicas o historias relacionadas por objetivo de negocio o área funcional.
- Épica: historia demasiado grande para completarse en un sprint. Debe dividirse en historias más pequeñas antes de incorporarse a una iteración.
- Historia de usuario: el nivel de trabajo del sprint. Completable en días o pocas semanas.
- Tarea: descomposición interna de una historia para facilitar el seguimiento diario.
La IA como herramienta en historias de usuario
Las herramientas de IA generativa pueden usarse como apoyo en algunas fases del trabajo con historias de usuario:
- Generación de variantes: a partir de una necesidad detectada en una entrevista de usuario, un modelo de lenguaje puede generar borradores de historias en formato Como/Quiero/Para que sirvan de punto de partida para la conversación del equipo.
- Detección de ambigüedades: la IA puede analizar historias ya escritas e identificar criterios de aceptación que podrían faltar, inconsistencias entre historias relacionadas o términos que admiten interpretaciones múltiples.
- Sugerencia de divisiones: para épicas grandes, la IA puede proponer formas de dividirlas aplicando estrategias como SPIDR (Spike, Path, Interface, Data, Rules).
La IA no comprende usuarios reales. Los modelos de lenguaje generan historias que suenan bien porque han visto miles de ejemplos similares, pero no tienen experiencia directa con los usuarios de tu producto. Una pila llena de historias con formato perfecto y criterios de aceptación detallados generados por IA puede parecer completa y no resolver ningún problema real. La IA puede ayudar a procesar y organizar información, pero no puede sustituir las conversaciones con usuarios reales. Toda historia generada con apoyo de IA requiere validación humana antes de incorporarse al sprint.
Consejos de buenas prácticas
- Escribir siempre el qué, evitar el cómo.
- No escribir una descripción exhaustiva: solo lo justo para recordar la conversación.
- Escribir los criterios de aceptación de forma suficientemente explícita.
- Estimar todas las historias: no hacerlo puede crear falsas expectativas.
- No fiar toda la información a las tarjetas: complementar con documentación externa cuando sea necesario.
- Nunca dar una historia por finalizada antes de cumplir todos los criterios de aceptación.
Error frecuente
Escribir la historia como una tarea técnica en lugar de como valor para el usuario. "Crear la tabla de usuarios en la base de datos" no es una historia de usuario: no describe ningún beneficio para nadie. Las historias hablan de resultados para quien usa el sistema, no de implementación técnica. Si la historia no puede expresarse en el formato Como/Quiero/Para de forma natural, probablemente sea una tarea técnica que pertenece al interior de otra historia.
Recursos
📄 Historias de usuario v.5.0Descarga gratuita · Scrum Manager · ene 2026
🎙️ Podcast Ep. 3: Cómo se crea una historia de usuarioScrum Manager Podcast · Spotify
📄 Cómo se crea una historia de usuarioScrum Manager Blog · ene 2023
🎙️ Podcast T2 Ep. 7: 5 características de una buena historia de usuarioScrum Manager Podcast · Spotify
Referencias
Wake, Bill. (2003). "INVEST in Good Stories, and SMART Tasks". XP123.
Cohn, Mike. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley.
Jeffries, Ron. (2001). "Essential XP: Card, Conversation, Confirmation". XProgramming.com.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.