Las Historias de Usuario son una de las herramientas más usadas en el mundo de la Agilidad. Vienen de Extreme Programming y han sido adoptadas en marcos de trabajo como Scrum. Pero escribirlas bien, y sacarles el provecho real, es otra cosa.
Hay que decir primero que las Historias de Usuario no son exclusivas de Scrum ni de la Agilidad. Son, en esencia, una manera de describir lo que un usuario hace en el sistema para completar una tarea determinada.
Nacieron como respuesta a una limitación de los requerimientos tradicionales, que describían todo desde la perspectiva del sistema:
El sistema debe permitir…
Las Historias de Usuario cambian ese enfoque y ponen al usuario en el centro:
Ana como ejecutiva de cuentas requiere… para…
La diferencia parece pequeña, pero no lo es. El usuario expresa su necesidad con sus propias palabras, sin lenguajes técnicos restrictivos, y eso luego se traduce a una perspectiva de sistema por quien corresponda.
Origen: Ron Jeffries y las 3 C’s
Las Historias de Usuario nacieron a finales de los años noventa dentro de Extreme Programming (XP). Su principal impulsor fue Ron Jeffries, uno de los firmantes del Manifiesto Ágil, quien formalizó la práctica a partir del proyecto C3 en Chrysler (1996). Fue allí donde el equipo buscaba una forma más humana y liviana de capturar lo que los usuarios necesitaban, y Jeffries articuló lo que hoy conocemos como las 3 C’s: Card, Conversation y Confirmation. La idea era simple y poderosa: una Historia no es un documento, es una promesa de conversación.
El Manifiesto Ágil y su conexión con las Historias de Usuario
El Manifiesto Ágil nos dice: “Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar…”. Cada uno de sus valores tiene una relación directa con cómo escribimos y usamos las Historias de Usuario:
| Principio | Relación con las Historias de Usuario |
|---|---|
| Individuos e interacciones sobre procesos y herramientas | Las Historias de Usuario crean un entendimiento compartido entre los miembros del equipo, los stakeholders y los usuarios finales. |
| Software funcionando sobre documentación extensa | Un acuerdo bien conversado reemplaza a decenas de páginas de actas. |
| Colaboración con el cliente sobre negociación contractual | La colaboración continua es lo que produce buenos productos. Una Historia de Usuario es, antes que nada, una invitación a esa conversación. |
| Respuesta ante el cambio sobre seguir un plan | El feedback del cliente es el mejor indicador de si vamos bien. Las Historias bien escritas permiten reaccionar sin que todo se caiga. |
Estos valores se traducen directamente en los principios ágiles: entregar valor de forma temprana y frecuente, trabajar en colaboración continua con el negocio, mantener un ritmo sustentable y maximizar el trabajo no hecho. Las Historias de Usuario son el vehículo práctico de todos esos principios.
Introducción a las Historias de Usuario
¿Qué son las Historias de Usuario y por qué se usan?
Es una pequeña unidad de trabajo que describe, desde la perspectiva del usuario, qué funcionalidad se necesita y por qué.
Su objetivo principal no es documentar, sino provocar una conversación. Mueve el foco de escribir requerimientos a conversar sobre los requerimientos, poniendo a los usuarios finales en el centro de la discusión.
Las Historias de Usuario además proveen un contexto no técnico para el equipo de desarrollo. Después de participar en una Historia de Usuario, el equipo sabe por qué están construyendo lo que están construyendo y qué valor aporta la solución. Eso importa más de lo que parece.
Al escribir una Historia de Usuario debes preguntarte tres cosas básicas:
- ¿Quién es tu cliente?
- ¿Qué lo satisface?
- ¿Qué necesita?
Cuando la necesidad del cliente es descompuesta en pequeñas funcionalidades es posible entregar valor en días o incluso en horas, y el equipo puede asegurarse de que está construyendo el producto correcto.
Formato de una Historia de Usuario
[who] As a <type of user>
[what] I would like <goal>
[why] So that <reason>
Siempre se expresa una Historia de Usuario desde la perspectiva del cliente. El “So that” (el para qué) no es opcional: da el contexto del valor que representa para el cliente y el negocio.
¿Quién escribe las Historias de Usuario y cuándo son escritas?
Todos los integrantes del equipo pueden escribir Historias de Usuario, aunque en la práctica lo hace más el Product Owner o el Analista de Negocio (Business Analyst), dado que están más tiempo cerca del cliente. Lo ideal es que el equipo sea experto en el cliente y en el producto, de forma que cualquiera pueda escribirlas y conversar sobre lo que viene en el Backlog. En la práctica, el Product Owner escribe la primera versión y el equipo ayuda a madurarla añadiendo detalles.
¿Cuándo son escritas? En todo momento en que llegan o surgen de conversaciones. En primera instancia suele ser un borrador que se va iterando con el equipo, pero lo importante es tomar nota de aquello que el usuario nos cuenta.
Hay que tener en cuenta que una idea por sí sola no es una Historia de Usuario. Hay que tomar un tiempo para conversarla y transformarla. Por eso es muy común manejar documentos o listas alternativas al Product Backlog para ir desarrollando esas ideas antes de formalizarlas.
Algunos momentos clave donde suelen surgir Historias nuevas o ajustes a las existentes:
- Los demos de producto, donde el feedback puede derivar en nuevas Historias o en ajustes a las existentes.
- Los Talleres de Historias de Usuario (Story Workshops), que son sesiones cada cierto periodo de tiempo, dos o tres meses, para escribir Historias para los siguientes meses, al menos en su versión inicial.
- El Backlog Refinement (o Grooming), donde se crean, descartan, estiman y dividen Historias existentes.
Las 3 C’s para escribir Historias de Usuario
Las 3 C’s son las recomendaciones de Ron Jeffries al escribir Historias de Usuario: Tarjeta (Card), Conversación (Conversation) y Confirmación (Confirmation).
La Historia debe ser lo suficientemente pequeña para que entre en una tarjeta y que invite a una conversación. La tarjeta conduce a una conversación entre el Product Owner y el equipo, que debe suceder en persona tanto como sea posible, y finalmente debe incluir una confirmación. Ese momento es cuando el equipo sabe realmente qué se debe hacer, y es cuando entran los criterios de aceptación.
Diferencias entre Requerimientos y Historias de Usuario
Muchas veces las solemos intercambiar pero no son lo mismo de ninguna manera. Existen tres diferencias clave:
Perspectiva:
- El requerimiento describe desde el sistema o la solución (“el sistema debe…”), y se usa en proyectos no ágiles, como metodologías en espiral o cascada.
- La Historia de Usuario lo mira desde el problema del cliente (“como supervisor… quiero… para…”), y es propia de proyectos ágiles.
Cómo son obtenidas:
- Para los requerimientos tradicionales, los Analistas de Negocio usan técnicas como entrevistas o encuestas para extraer información, que luego documentan en instrumentos como un BRD (Business Requirement Document). Suele ser una actividad única: el Analista obtiene las respuestas, las documenta y pasa a lo siguiente.
- En ágil, la Historia de Usuario es una discusión y un esfuerzo colaborativo. La manera en que se escribe impulsa conversaciones: ¿por qué lo necesitan realmente?, ¿cuáles son los detalles?, ¿qué sabemos y qué no?, ¿cuáles son los matices que la componen? Es un trabajo de salida constante de información que asegura considerar todas las piezas desde la perspectiva del usuario.
Quién es el dueño:
- Los requerimientos tradicionales pertenecen a quien los escribió, en su lenguaje y desde su perspectiva. Generalmente el Analista de Negocio es su dueño, lo que implica que suele necesitar explicar el documento a otros y gestionar los cambios en su sintaxis y estructura.
- En el enfoque ágil, el dueño es el grupo. Se escribió en conjunto, en conversaciones, desde la perspectiva del usuario y en lenguaje natural. Todos sienten que pusieron algo de su parte y que ayudaron a construir esa Historia de Usuario.
Diferencias entre Casos de Uso y Historias de Usuario
Ambos describen la misma meta pero tienen propósitos distintos. Las Historias de Usuario hablan de necesidades; los Casos de Uso explican el comportamiento que el sistema debe tener para satisfacerlas, y suelen cubrir las interacciones completas del sistema, a veces con sistemas externos. Son complementarios, no equivalentes.
Roles de Usuario
Cuando escribes Historias de Usuario vas a querer conocer a los usuarios: qué rol cumplen, cómo operan, qué necesitan. Sueles terminar con muchos roles distintos, y describirlos a todos en cada Historia se vuelve inmanejable, por eso se recomienda agruparlos en roles que compartan necesidades, intereses, expectativas y comportamientos. La recomendación es hacer una lluvia de ideas de todos los roles posibles y luego refinar y agrupar esa lista, algo que puede hacerse como parte de la Inception Ágil del proyecto.
Personas
Una vez que tienes los roles puedes crear las “Personas”, de forma que puedas visualizar mejor esa clase de persona. Una Persona es una representación ficticia del usuario, similar a la figura que se usa en procesos como el Customer Journey Map.
Más de las Historias de Usuario
-
Las Historias de Usuario son como un punto de partida en donde puedes tener documentos de respaldo, wireframes, maquetas de UI, diagramas de flujo y otras representaciones visuales de requisitos. No subestimes esta parte: a menudo son el entendimiento común que los stakeholders necesitan.
-
No asumas que una Historia de Usuario tiene funcionalidades implícitas. Por ejemplo, una Historia que habla de crear registros frecuentemente omite la actualización de esa información, lo que puede causar problemas si actualizar implica recálculo de otros valores o reprogramación de actividades. Sé explícito: describe si la Historia incluye el CRUD completo o si hay otras Historias que cubren esas funciones.
-
El “¿Por qué?” es fundamental y no debe quedar implícito. Da el contexto del valor que representa la Historia, ayuda a priorizarla en el Backlog y, al retomar la conversación después de un tiempo, permite saber qué se buscaba y por qué era importante.
-
Hay veces que una Historia involucra una funcionalidad compartida entre dos o más roles. Por ejemplo, dar de alta a un usuario puede hacerlo el propio usuario o un administrador. Aunque las pantallas e inputs sean similares, no tienen los mismos detalles ni accesos. En esos casos está bien y es correcto tener dos Historias de Usuario que representen cada caso con sus particularidades.
Criterios de Aceptación
Entendiendo los Criterios de Aceptación
Una Historia de Usuario por sí sola no tiene suficientes detalles para que alguien pueda construir una solución con confianza. Ahí entran los criterios de aceptación: condiciones que el producto debe cumplir para considerarse terminado.
Hay cuatro beneficios principales de los criterios de aceptación:
- Crea un entendimiento común: provee los detalles necesarios en una solución como criterio compartido por los stakeholders.
- Define el alcance: le dice a los creadores de la solución dónde empezar y dónde terminar, y qué es lo importante.
- Valida que una Historia de Usuario está completada: provee un checklist o condiciones que al ser alcanzadas indican que finalizó de forma certera.
- Muestra qué probar y si pasa la prueba la solución entregada.
Los detalles que faltan suelen surgir a través de preguntas concretas sobre qué información se muestra, cómo se obtiene, quién tiene acceso o qué significa un término en ese contexto. Esas preguntas fluyen con las conversaciones y van construyendo los criterios de forma gradual.
Cómo se escriben
Hay dos formatos comunes:
- Checklist: una lista de condiciones que, al cumplirse todas, indican que la solución es exitosa.
- Given-When-Then: estructura usada en pruebas BDD (Behavior Driven Development), que describe el contexto, la acción y el resultado esperado.
¿Quién los escribe y cuándo?
El Product Owner generalmente escribe la Historia de Usuario inicial. Luego, la responsabilidad de definir los criterios de aceptación suele recaer en el Analista de Negocio, quien aplica su experiencia en análisis y elicitación para documentarlos con precisión.
Normalmente, al crear una Historia de Usuario no se incluyen de inmediato los criterios de aceptación. Estos se van construyendo a lo largo del tiempo mediante conversaciones, a medida que la Historia madura.
Ninguna Historia de Usuario debería entrar en el Sprint Backlog si la misma no tiene criterios de aceptación.
Buenas prácticas
- Escríbelos en lenguaje simple, evitando tecnicismos y modismos, de forma que sean legibles para todos los integrantes del equipo.
- Describe la intención, no la solución técnica.
- Mantenlos medibles, evitando puntos grises; es decir, cada criterio debe poder evaluarse de forma clara, en términos de cumplimiento o no cumplimiento.
- Las listas extensas de criterios de aceptación son aceptables y suelen ser una señal para evaluar si la Historia necesita dividirse.
Escribir mejores Historias de Usuario con INVEST
INVEST es un acrónimo que resume las características de una buena Historia de Usuario. Funciona como lista de verificación antes de llevarla a un Sprint.
- Independiente: ¿depende de otra Historia para poder implementarse? Las dependencias complican la planificación y pueden bloquear trabajo de alta prioridad por culpa de trabajo de baja prioridad.
- Negociable: no es un contrato. Es una invitación a conversar los detalles, tiempos y criterios de aceptación. Si nadie puede cuestionarla, algo falla.
- Valiosa: el valor debe estar claro para todo el equipo, no solo desde la perspectiva del usuario sino en relación a los objetivos del negocio. Muchas Historias parecen valiosas pero no lo son frente a las prioridades reales.
- Estimable: debe tener suficiente detalle para que el equipo pueda estimarla. No todos los detalles, pero sí los relevantes.
- Small (Pequeña): si no puede completarse en un Sprint, es demasiado grande. Divídela. Y si puede completarse sin dividirse, no lo hagas: dividir sin necesidad genera sensación de trabajo incompleto.
- Testeable: debe poder verificarse que la implementación es correcta. Si no se puede testear, probablemente está mal definida.
Recuerda que INVEST es una guía, no reglas estrictas. Hay que tomarlas en cuenta para construir el Backlog, pero no tratar de forzar cada idea dentro de estos criterios.
Non-Historias de Usuario
Entendiendo los Spikes
No todo lo que va al Backlog es una Historia de Usuario de negocio. Hay aspectos de la solución que requieren investigación previa: ahí entran los Spikes.
Un Spike es una investigación, técnica o de diseño, que genera el conocimiento necesario para resolver algo en el Backlog. Su resultado no es software funcionando, sino respuestas: ¿es esto técnicamente factible?, ¿hay opciones que deberíamos evaluar primero?, ¿cuáles son los riesgos? Puede derivar en una nueva Historia de Usuario, en la actualización de una existente, o simplemente en reducir la incertidumbre de algo que el equipo no sabe cómo estimar.
Los Spikes se documentan como cualquier otro ítem del Backlog, se priorizan y se incluyen en un Sprint cuando corresponde. Deben tener criterios de aceptación que definan qué preguntas tienen que quedar respondidas al final.
Un detalle importante: los Spikes deben tener un límite de tiempo (timebox). Es muy fácil entusiasmarse con la investigación y perder el foco.
Historias técnicas y de infraestructura
Hay necesidades que no tienen que ver con el usuario ni con el negocio directamente, sino con la capacidad de construir el producto: implementación de herramientas de testing, automatización de despliegues, configuración de servidores, esquemas de seguridad externos. Estas Historias tienen el mismo tratamiento que las de negocio: criterios de aceptación, priorización en el Backlog e inclusión en un Sprint cuando corresponda. El «como…» puede ser incómodo aquí, pero a menudo el usuario que necesita esa funcionalidad es el propio equipo de desarrollo o el arquitecto.
Estimando Historias de Usuario
Conceptos generales
En metodologías tradicionales las estimaciones van en horas o días. En proyectos ágiles son relativas: se comparan Historias entre sí y se agrupan según su complejidad percibida.
Dos técnicas comunes:
- T-shirt sizing: pequeña, mediana, grande. Simple y rápido para una primera pasada.
- Serie de Fibonacci: asigna números de la serie (1, 2, 3, 5, 8, 13…) a cada Historia. Estos números se conocen como Story Points.
La lógica de Fibonacci es útil porque los saltos entre números crecen a medida que la escala sube, lo que refleja mejor la incertidumbre al estimar tareas grandes. Una Historia con un número mayor a 8 es una señal para dividirla antes de llevarla al Sprint.
La cantidad de Story Points que el equipo implementa en un Sprint es su velocidad. El promedio de varias iteraciones da una referencia para planificar. Al principio esa referencia no existe: se construye con el tiempo. Y vale aclararlo: los puntos no son comparables entre equipos, porque la estimación es siempre relativa al contexto propio de cada uno.
Las Épicas
Cuando una Historia es tan grande que no tiene sentido estimarla con la escala habitual, se la marca como Épica. Eso significa que necesita un análisis más profundo antes de poder dividirse en Historias implementables.
Una Épica no es un problema: es una conversación pendiente sobre cómo descomponerla en partes que el equipo pueda implementar en un Sprint.
Una técnica muy útil para trabajar con Épicas es el User Story Mapping de Jeff Patton, que organiza las Historias en un mapa bidimensional: el flujo del usuario en el eje horizontal y la profundidad o prioridad de cada funcionalidad en el vertical. Permite ver el producto completo de un vistazo y entender mejor cómo dividir las Épicas en entregas incrementales.
Dividiendo las Historias de Usuario
Introducción al Splitting
Las Historias grandes que no caben en una iteración necesitan dividirse. El objetivo es llegar a Historias suficientemente pequeñas para implementarse en un Sprint y que, de ser posible, cumplan con los principios INVEST.
¿Por qué dividir?
Al dividir una Historia grande, suele quedar claro que algunas partes no son tan prioritarias como parecían, y eso permite enfocar el esfuerzo en lo que realmente aporta valor. Dividir también fuerza al equipo a clarificar detalles que de otro modo quedan en el aire, reduce el riesgo de dar compromisos que no se pueden cumplir, y hace las estimaciones más confiables.
Y la razón más práctica: algunas Historias entregadas son mejor que ninguna Historia entregada.
Dividiendo con simplicidad
Empieza con la opción simple y añade variaciones en iteraciones posteriores.
Ejemplo:
- Historia A: como comprador, quiero poder hacer transferencias bancarias para cancelar mi pedido.
Dividiéndola:
- A-1: como comprador, quiero hacer transferencias bancarias manuales para cancelar mi pedido.
- A-2: como comprador, quiero hacer transferencias mediante link de pagos de mi banco para cancelar mi pedido.
- A-3: como comprador, quiero hacer transferencias conectando automáticamente con mi banco para cancelar mi pedido.
Dividiendo por flujo de trabajo
Las Historias grandes suelen esconder varios pasos. “Comprar en la tienda en línea” puede dividirse en:
- Buscar productos
- Comparar productos
- Seleccionar forma de pago
- Crear cuenta
- Especificar dirección de entrega
Cada paso puede ser en sí mismo una Historia de Usuario, por lo que una forma bastante evidente de dividir es discutir el proceso que envuelve el cumplimiento de la Historia grande.
Dividiendo por CRUD
Si alguna operación de un registro (crear, leer, actualizar, borrar) tiene una complejidad particular o la usa un rol distinto, puede separarse. En la mayoría de casos el CRUD completo es una sola Historia, pero las búsquedas, reportes o clasificaciones asociadas pueden ser Historias adicionales.
Dividiendo por método de ingreso
Cuando una Historia involucra ingresar información por varios canales, cada canal puede ser una Historia distinta. “Añadir fotos a un documento” puede hacerse desde el sistema de archivos, mediante URL o desde un servicio externo como Pexels. Cada método tiene su propia complejidad y puede implementarse de forma independiente.
Dividiendo con Spikes
Si antes de implementar algo el equipo necesita investigar cómo hacerlo, esa investigación puede separarse como un Spike con criterios de aceptación propios. El Spike responde las preguntas; la Historia implementa la solución.
El Spike debe tener un timebox claro para no dilatar los objetivos con investigación interminable.
Lo que no hay que hacer
- No agrandar la iteración para que quepa la Historia. Si no cabe, se divide.
- No dividir por fases técnicas: diseño, desarrollo y testing no entregan valor por separado.
- No asumir que una Historia no se puede dividir sin haberlo intentado de verdad. Con las preguntas correctas, casi siempre se encuentra la forma.
Retos comunes al gestionar Historias de Usuario
El “quién” y el “para qué”
Escribir “como usuario” sin especificar qué tipo de usuario no ayuda al equipo. El usuario debe ser concreto: un supervisor, un cliente nuevo, un administrador. Esa especificidad cambia el enfoque de la solución.
El “para qué” es igual de importante. Sin ese contexto, es difícil priorizar y difícil diseñar la solución correcta. A menudo el “para qué” lleva a preguntas adicionales que clarifican detalles que nadie había considerado.
Manejo de bugs y defectos
Los bugs aparecen. La tentación habitual es encontrar tiempo mágico dentro del Sprint para arreglarlos, pero eso afecta la velocidad del equipo y la planificación comprometida con los stakeholders.
Lo recomendable es documentarlos como cualquier otro ítem del Backlog, estimarlos, agregarles criterios de aceptación y priorizarlos. No todos los bugs son urgentes: algunos pueden esperar; otros no. Pero esa decisión debe tomarse de forma consciente, no apagando incendios.
Dependencias entre Historias
La mejor forma de lidiar con dependencias es no tenerlas, y para eso ayuda el principio de Independencia de INVEST. Un caso típico es cuando una historia complementa a otra: la historia base debería haberse implementado en una iteración anterior, porque planificarlas en el mismo Sprint genera tiempos muertos y desperdicio.
Cuando las dependencias aparecen, hay varias salidas: combinar las historias en una sola y replantear su división; intercambiar requisitos entre ellas hasta lograr que cada una sea independiente; o, si ninguna de las anteriores funciona, monitorear el impacto y asegurarse de que la implementación no genere problemas al negocio.
Cambios durante el Sprint
Es importante diferenciar el Product Backlog del Sprint Backlog. Ambos contienen Historias de Usuario, pero el Sprint Backlog incluye solo aquellas que ya han sido priorizadas, estimadas y validadas (por ejemplo con INVEST), y que además fueron acordadas con los stakeholders antes de iniciar el Sprint.
El Sprint, normalmente de dos semanas, se basa en esas historias como compromiso del equipo. No se deben agregar historias una vez iniciada la iteración: introduce trabajo no analizado y rompe la planificación acordada con los stakeholders. Si surge una necesidad urgente, debe madurar en el Backlog e incluirse en un Sprint futuro.
El Sprint es un compromiso de trabajo del equipo con los stakeholders.
Conclusiones
Las Historias de Usuario son una de las herramientas más poderosas de la Agilidad, nacidas en Extreme Programming y adoptadas hoy por marcos como Scrum. Su fortaleza radica en generar conversaciones reales sobre la necesidad del cliente que se enriquecen con el tiempo a través de diagramas, flujos, documentos y criterios que maduran la solución.
Esas conversaciones derivarán en Historias cada vez más pequeñas, hasta llegar a una que el equipo pueda implementar en un Sprint y entregar valor concreto. Ese es el ciclo, y funciona cuando el equipo lo interioriza como hábito, no como obligación.
Escribir buenas Historias de Usuario es una habilidad que se afina con la práctica. El formato, INVEST, los criterios de aceptación, el splitting: son herramientas, no recetas. Lo que realmente importa es mantener al usuario en el centro de cada conversación.
Esperamos que esta guía les ayude a desarrollar esa habilidad y a entregar cada vez más valor a sus clientes.