View source for Historia de usuario

{{Meta-bok|min=6}}
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.
<br>
[[File:HistoriaUsuario.png|500px|thumb|center|'''Ejemplo de historia de usuario''']]

== 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.
* '''[[Epic|É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).

<div class="bok-aviso">
'''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.
</div>

== Consejos de buenas prácticas ==
Del manual ''Historias de usuario'' v5.0 de Scrum Manager:

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 ==
<div class="bok-aviso">
'''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.
</div>
== Recursos ==
<div class="bok-recurso">
📄 [https://www.scrummanager.com/files/scrum_manager_historias_usuario.pdf Manual: Historias de usuario v5.0]<span class="detalle">Descarga gratuita · Scrum Manager · ene 2026</span>
</div>
<div class="bok-recurso">
🎙️ [https://open.spotify.com/episode/07cSgNf9znGHU93kAm2qaU Podcast Ep. 3: Cómo se crea una historia de usuario]<span class="detalle">Scrum Manager Podcast · Spotify</span>
</div>
<div class="bok-recurso">
📄 [https://www.scrummanager.com/blog/2023/01/como-se-crea-una-historia-de-usuario/ Blog: Cómo se crea una historia de usuario]<span class="detalle">Scrum Manager Blog · ene 2023</span>
</div>
<div class="bok-recurso">
🎙️ [https://open.spotify.com/episode/5PMBIIhu0cuW9GkA2xNGV5 Podcast T2 Ep. 7: 5 características de una buena historia de usuario]<span class="detalle">Scrum Manager Podcast · Spotify</span>
</div>
== 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 ==
<div class="bok-tags">
[[INVEST]] [[Criterios de aceptación]] [[Epic]] [[Tema]] [[Tarea]] [[Pila del producto]] [[Backlog refinement]] [[A punto]] [[Requisitos ágiles]] [[Mapa de historias]]
</div>
<div class="bok-ecosistema">
<div class="texto">
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
<span class="sub">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 [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
</div>
<div class="botones">
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
</div>
</div>
[[Category:Glosario de términos]]
[[Category:Product_Management]]
[[Category:Standard scrum]]
[[Category:Scrum]]