Historias de Usuario: Cómo Escribirlas (Con Ejemplos y Plantilla)

Las historias de usuario son descripciones breves en lenguaje sencillo de una funcionalidad contada desde la perspectiva de quien la va a usar. Son la base de la mayoría de los Backlogs de Agile y Scrum y, cuando están bien escritas, mantienen a los equipos de desarrollo enfocados en resultados reales para el usuario en lugar de requisitos técnicos abstractos.

¿Qué son las historias de usuario?

Una historia de usuario es una descripción breve e informal de una funcionalidad de software desde el punto de vista del usuario final. No es una especificación técnica. Es un marcador de posición para una conversación sobre lo que un usuario necesita y por qué esa necesidad importa para el producto.

El término se popularizó a través de Extreme Programming (XP) a finales de la década de 1990 y fue codificado por Mike Cohn en su libro de 2004 User Stories Applied. Hoy en día, las historias de usuario son una práctica estándar en los equipos ágiles, desde startups de dos personas hasta divisiones de productos empresariales.

Las historias de usuario mantienen a los equipos honestos. En lugar de construir funcionalidades porque suenan técnicamente interesantes, los equipos escriben historias de usuario para mantenerse anclados a las personas para quienes están construyendo. La historia en sí misma es breve por diseño. El valor proviene de la conversación que desencadena entre los product owners, los desarrolladores y las partes interesadas.

Datos clave

• Las historias de usuario fueron popularizadas por Kent Beck como parte de Extreme Programming (XP) a finales de la década de 1990 y luego formalizadas en el libro de Mike Cohn de 2004 User Stories Applied.
• Según el 17.º State of Agile Report (Digital.ai, 2023), el 83% de los equipos ágiles usan historias de usuario como su formato principal para capturar requisitos.
• Los equipos que usan criterios de aceptación bien estructurados junto con las historias de usuario reportan un 40% menos de defectos en las revisiones del Sprint, según una encuesta de profesionales de Scrum Alliance de 2022.

La Plantilla de Historia de Usuario

El formato clásico de historia de usuario tiene tres partes. Lo encontrará en todas partes:

Como [rol], quiero [objetivo], para que [beneficio].

Cada parte cumple una función específica.

Completa: "Como comprador por primera vez, quiero guardar artículos en una lista de deseos, para poder volver a ellos más tarde sin buscar de nuevo."

Este formato funciona porque obliga a los equipos a pensar en tres cosas a la vez: quién, qué y por qué. Elimine cualquiera de ellas y la historia se vuelve mucho más difícil de priorizar o estimar. Una historia sin la cláusula "para que" es solo una tarea. No dice qué valor se está creando, lo que hace casi imposible decidir si vale la pena construirla en el momento de planificar el Sprint.

Historias de Usuario vs. Épicas vs. Tareas

Las historias de usuario se ubican en el nivel intermedio de una jerarquía de tres niveles. Definir la granularidad correcta importa mucho cuando se está ejecutando la planificación del Sprint.

Las épicas son demasiado grandes para construirse en un Sprint, por lo que los equipos las descomponen en historias de usuario. Las historias se dimensionan para caber dentro de un Sprint. Las tareas son el trabajo técnico concreto que los desarrolladores toman y rastrean en un tablero.

Un error frecuente es escribir historias con el alcance de una épica y luego preguntarse por qué nada se termina. Si una historia tarda más de un Sprint en completarse, probablemente es una épica disfrazada. Hay que descomponerla.

Las 3 Cs de las Historias de Usuario

Ron Jeffries introdujo el marco de las 3 Cs para describir cómo funcionan realmente las historias de usuario en la práctica. La tarjeta es solo el punto de partida.

Tarjeta (Card). Una historia de usuario se escribe tradicionalmente en una tarjeta de índice física (o su equivalente digital). La tarjeta es breve por diseño: una o dos oraciones. No es la especificación completa. Es un recordatorio de que debe ocurrir una conversación.

Conversación (Conversation). La tarjeta desencadena una discusión entre el product owner, los desarrolladores y, con frecuencia, las partes interesadas. Esta conversación es donde se trabajan los requisitos reales. La tarjeta no contiene todas las respuestas. Las personas sí.

Confirmación (Confirmation). Una vez que ocurre la conversación, el equipo documenta los criterios de aceptación: las condiciones específicas que deben cumplirse para que la historia se considere completada. Estos criterios son los que se prueban y verifican antes de cerrar la historia.

La mayoría de los equipos escribe la tarjeta y pasa directamente a programar. Eso es al revés. La etapa de conversación es donde se resuelve la ambigüedad, se descubren los casos límite y se construye el entendimiento compartido. Las historias que omiten la conversación tienden a volver para ser reelaboradas.

Criterios INVEST para Buenas Historias de Usuario

Bill Wake introdujo el acrónimo INVEST para dar a los equipos una lista de verificación de calidad para evaluar si una historia de usuario está bien formulada. Pase cualquier historia por esta lista antes de incluirla en un Sprint.

Haga una verificación INVEST rápida durante la refinación del Backlog. Si una historia falla en algún criterio, no la lleve a la planificación todavía. Corríjala primero. Los fallos más frecuentes son "no es suficientemente pequeña" (debería ser una épica) y "no es comprobable" (aún no se han escrito los criterios de aceptación).

Cómo Escribir una Historia de Usuario

Escribir una buena historia de usuario requiere más que completar la plantilla. Este es el proceso que funciona de manera confiable.

Paso 1: Identifique su persona de usuario

¿Quién va a usar realmente esta funcionalidad? Sea específico. "Los usuarios" no es una persona. "Los nuevos usuarios que aún no han configurado el pago" sí lo es. Cuanto más concreta sea la persona, más fácil será escribir una historia que refleje realmente sus necesidades.

Si aún no tiene personas formales, una conversación rápida con su equipo de soporte al cliente identificará los tipos de usuarios más comunes en unos 20 minutos.

Paso 2: Nombre el objetivo

¿Qué intenta lograr el usuario? Escríbalo como una acción: "filtrar los resultados de búsqueda por precio", "exportar datos como un archivo CSV", "recibir un correo de confirmación después del pago". Manténgalo en un objetivo por historia. Si se encuentra escribiendo "y" en el objetivo, probablemente tiene dos historias.

Paso 3: Declare el beneficio

¿Por qué quiere esto el usuario? ¿Qué resultado busca? Esta es la cláusula "para que". También es la parte que más se omite. No la omita. El beneficio le dice al equipo cómo se ve el éxito, lo que importa cuando surgen compensaciones durante el desarrollo.

Paso 4: Agregue criterios de aceptación

Escriba las condiciones que la funcionalidad debe cumplir para considerarse completa. Use lenguaje sencillo o el formato Dado/Cuando/Entonces (más información a continuación). Los criterios de aceptación no son opcionales. Sin ellos, cada desarrollador del equipo tiene un modelo mental ligeramente diferente de lo que significa "terminado".

Paso 5: Estime la historia

Trabaje con el equipo para dimensionar la historia usando Story Points u un método de estimación relativa similar. Si la estimación es alta (generalmente por encima de 8 o 13 en una escala Fibonacci), la historia probablemente es demasiado grande. Descompóngala en piezas más pequeñas antes de la planificación del Sprint.

Paso 6: Priorice y refine

Agregue la historia al Product Backlog y clasifíquela por valor. Durante las sesiones de refinación del Backlog, revise las historias que se acercan al próximo Sprint para asegurarse de que siguen siendo relevantes, están dimensionadas correctamente y tienen criterios de aceptación claros. Las historias que no han sido refinadas recientemente suelen necesitar actualización antes de estar listas para el Sprint.

Ejemplos de Historias de Usuario

Aquí se presentan ejemplos concretos en tres tipos comunes de productos. Cada uno sigue la plantilla estándar e incluye una nota breve de aceptación.

Note que cada historia nombra un tipo de usuario específico, no un "usuario" genérico. Y cada cláusula de beneficio explica la motivación real, no solo una repetición del objetivo.

Criterios de Aceptación y Definition of Done

Los criterios de aceptación son las condiciones específicas que una funcionalidad debe satisfacer para que el equipo considere la historia de usuario completa. Se escriben antes de que comience el desarrollo, generalmente durante la etapa de conversación.

El formato más común es Dado/Cuando/Entonces (también llamado sintaxis Gherkin):

• Dado algún contexto inicial o condición previa
• Cuando el usuario realiza una acción específica
• Entonces ocurre un resultado específico

Ejemplo para la historia de la lista de deseos:

Dado que un comprador con sesión iniciada está viendo una página de producto
Cuando hace clic en el botón "Guardar en lista de deseos"
Entonces el artículo se agrega a su lista de deseos y aparece una notificación de confirmación; el botón cambia a "Guardado"

La Definition of Done (DoD) es diferente de los criterios de aceptación. Los criterios de aceptación son específicos para una historia. La DoD es un estándar a nivel de equipo que se aplica a cada historia: pruebas unitarias escritas, código revisado, desplegado en staging, sin errores críticos. Ambos deben cumplirse antes de cerrar una historia.

No los confunda. Una historia puede cumplir todos sus criterios de aceptación y aun así no cumplir la DoD si, por ejemplo, no hubo revisión de código. Rastrée ambos.

Errores Comunes al Escribir Historias de Usuario

Escribir desde la perspectiva del sistema, no del usuario. "El sistema enviará un correo electrónico" es un requisito técnico, no una historia de usuario. Vuélvalo a escribir: "Como nuevo usuario, quiero recibir un correo de bienvenida después de registrarme, para saber que mi cuenta fue creada con éxito."

Omitir la cláusula de beneficio. "Como usuario, quiero filtrar resultados" no le dice casi nada al equipo sobre la prioridad o el valor. ¿Por qué quiere el usuario filtrar? ¿Qué decisión tomará con los resultados filtrados? En la cláusula "para que" es donde vive la información real.

Escribir épicas y llamarlas historias. "Como usuario, quiero una experiencia de pago completa" no es una historia. Es un área de funcionalidad. Hay que descomponerla en piezas específicas y estimables: selección del método de pago, confirmación del pedido, correo de recibo, etc.

No tener criterios de aceptación antes de que comience el desarrollo. Las historias sin criterios de aceptación son una invitación abierta a la reelaboración. Los desarrolladores interpretan la ambigüedad de la manera más fácil de construir, no necesariamente la que el product owner tenía en mente. Escriba los criterios antes de que comience el Sprint.

Demasiadas historias para un Sprint. Los equipos ágiles a veces sobrecargan el Backlog con más historias de las que el equipo puede terminar de manera realista. Esto lleva a trabajo a medias y a un "burndown chart" inflado que nunca llega a cero. Use Story Points y la velocidad histórica para establecer una capacidad de Sprint realista.

Ignorar el paso de priorización MoSCoW. No todas las historias de usuario son iguales. Algunas son indispensables; otras son agradables de tener. Sin una priorización explícita, los equipos invierten tiempo del Sprint en historias de bajo valor mientras el trabajo de alto valor espera.

Preguntas Frecuentes

¿Qué es una historia de usuario en Agile?

Una historia de usuario es una descripción breve en lenguaje sencillo de una funcionalidad desde la perspectiva del usuario, escrita en el formato "Como [rol], quiero [objetivo], para que [beneficio]". Se usa en equipos ágiles para capturar requisitos de manera que mantiene el enfoque en el valor para el usuario en lugar de en las especificaciones técnicas. Las historias de usuario generalmente se almacenan en un Product Backlog y se incluyen en los Sprints según la prioridad.

¿Cuál es la diferencia entre una historia de usuario y una épica?

Una épica es un conjunto amplio de trabajo que es demasiado grande para entregarse en un Sprint. Una historia de usuario es una porción más pequeña y entregable de ese trabajo. Las épicas se descomponen en historias de usuario. Por ejemplo, "Experiencia de pago" es una épica. "Como comprador, quiero guardar mis datos de pago para compras futuras" es una historia de usuario dentro de ella.

¿Quién escribe las historias de usuario?

El product owner generalmente escribe o gestiona las historias de usuario, pero las mejores historias provienen de la colaboración. Los product owners aportan la perspectiva de negocio y del usuario. Los desarrolladores aportan el contexto técnico. Los diseñadores de UX aportan la investigación de usuarios. Las sesiones de refinación del Backlog son donde estas perspectivas se combinan para producir historias bien formuladas y estimables.

¿Qué son los Story Points?

Los Story Points son una unidad de estimación relativa que los equipos usan para dimensionar las historias de usuario. En lugar de estimar en horas (lo que varía por persona y suele ser impreciso), los equipos comparan las historias entre sí usando una escala tipo Fibonacci (1, 2, 3, 5, 8, 13). Una historia de 5 puntos es aproximadamente el doble de compleja que una de 2 puntos. Con el tiempo, los equipos desarrollan una Velocity estable (puntos por Sprint), lo que hace que la planificación del Sprint sea más predecible.

¿Qué significa INVEST en las historias de usuario?

INVEST es una lista de verificación de calidad para las historias de usuario: Independiente (puede construirse sin depender de otra historia), Negociable (los detalles pueden cambiar según la conversación), Valiosa (entrega valor claro al usuario), Estimable (el equipo puede dimensionarla), Pequeña (cabe en un Sprint) y Comprobable (tiene criterios de aceptación verificables). Si una historia falla en alguno de estos criterios, no está lista para un Sprint.

---

Las buenas historias de usuario no se escriben solas. Pero los equipos que se toman el tiempo de hacerlas bien: nombrando personas de usuario reales, escribiendo cláusulas de beneficio claras y adjuntando criterios de aceptación comprobables antes de que comience el desarrollo, invierten menos tiempo en reelaboración y más tiempo entregando cosas que importan.

Comience con una historia para el elemento de mayor prioridad en su Backlog actual. Aplique la plantilla, ejecute la verificación INVEST y escriba dos o tres criterios de aceptación. Ese es el hábito. Constrúyalo desde ahí.

Para marcos relacionados, consulte la estructura de desglose del trabajo para descomponer el alcance del proyecto, la planificación del Sprint para incluir historias en los Sprints, y Scrum vs. Kanban si está decidiendo qué flujo de trabajo se adapta mejor a su equipo.