Las historias de usuario son una forma breve de expresar una necesidad desde la perspectiva de quien recibirá valor del sistema. Se usan mucho en enfoques ágiles porque ayudan a conversar sobre lo que se necesita, para quién y con qué propósito.
Una historia de usuario no es una especificación completa por sí sola. Es un recordatorio de una conversación que debe completarse con detalles, reglas, datos, criterios de aceptación y validación.
En este tema veremos su estructura, utilidad, límites y buenas prácticas para usarlas correctamente dentro de los requerimientos de software.
Una historia de usuario describe una necesidad o capacidad esperada en lenguaje simple, normalmente desde el punto de vista de un usuario, cliente o actor interesado.
Su objetivo es mantener el foco en la persona o rol que necesita algo y en el beneficio esperado, evitando empezar directamente por detalles técnicos o pantallas.
El formato más conocido es:
Ejemplos:
Este formato no es obligatorio, pero ayuda a ordenar rol, necesidad y valor.
Una historia de usuario bien formulada suele incluir tres elementos:
| Elemento | Pregunta que responde | Ejemplo |
|---|---|---|
| Rol | ¿Quién necesita esta capacidad? | Como vendedor... |
| Capacidad | ¿Qué quiere poder hacer? | ...quiero consultar stock disponible... |
| Beneficio | ¿Para qué lo necesita? | ...para confirmar pedidos durante visitas a clientes. |
El beneficio es importante porque permite entender el valor y priorizar mejor.
Una historia de usuario no debe verse como un texto cerrado. Debe iniciar conversaciones entre interesados, analistas, desarrolladores y testers.
Por ejemplo, la historia "Como cliente, quiero consultar mi pedido" genera preguntas:
Estas preguntas completan el análisis que la historia por sí sola no contiene.
Las historias de usuario son útiles porque:
Son especialmente valiosas cuando el producto evoluciona por incrementos.
Una guía conocida para evaluar historias de usuario es INVEST. Cada letra representa una característica deseable.
| Letra | Significado | Idea principal |
|---|---|---|
| I | Independiente | Puede desarrollarse con pocas dependencias innecesarias. |
| N | Negociable | Es una base para conversar, no un contrato rígido. |
| V | Valiosa | Aporta valor a un usuario, cliente o interesado. |
| E | Estimable | El equipo puede estimar su esfuerzo con información suficiente. |
| S | Pequeña | Puede completarse en un período razonable. |
| T | Testeable | Puede verificarse mediante criterios de aceptación o pruebas. |
Una historia demasiado grande se conoce a menudo como épica. Describe una necesidad amplia que debe dividirse en historias más pequeñas.
Ejemplo de historia grande:
Puede dividirse en historias más específicas:
Una historia débil suele describir una tarea técnica o una pantalla sin explicar valor.
| Historia débil | Problema | Mejora posible |
|---|---|---|
| Como usuario, quiero una pantalla de búsqueda. | No indica qué busca ni para qué. | Como operador, quiero buscar reclamos por cliente o número, para responder consultas rápidamente. |
| Como sistema, quiero guardar datos. | No expresa un usuario ni valor claro. | Como vendedor, quiero guardar un pedido como borrador, para completarlo cuando el cliente confirme datos faltantes. |
| Como administrador, quiero un reporte. | No indica contenido ni propósito. | Como supervisor, quiero ver reclamos vencidos por responsable, para reasignar trabajo pendiente. |
Los criterios de aceptación complementan la historia. Indican condiciones que deben cumplirse para considerar que la historia fue implementada correctamente.
Ejemplo:
Sin criterios de aceptación, la historia puede interpretarse de varias maneras.
Muchas historias requieren reglas de negocio asociadas. La historia expresa la necesidad, pero la regla define condiciones específicas.
Ejemplo:
Las reglas deben documentarse aunque no entren cómodamente en la frase de la historia.
Las historias también deben completarse con datos requeridos. Por ejemplo, "registrar un cliente" exige definir qué datos son necesarios.
Preguntas útiles:
Una historia sin datos suficientes puede ser difícil de estimar, diseñar y probar.
A veces se habla de historias técnicas para expresar trabajo necesario que no entrega valor visible directamente a un usuario final, pero habilita capacidades importantes.
Ejemplos:
Conviene usarlas con cuidado. Aunque no tengan un usuario final evidente, deben relacionarse con una necesidad, restricción, riesgo o atributo de calidad.
Una historia de usuario no es lo mismo que una tarea técnica. La historia describe valor o necesidad; las tareas describen trabajo que el equipo realiza para implementarla.
| Historia | Tareas posibles |
|---|---|
| Como cliente, quiero consultar el estado de mi pedido, para conocer cuándo será entregado. | Crear consulta de pedidos, diseñar vista, validar permisos, agregar pruebas, integrar con datos de logística. |
| Como administrador, quiero asignar roles a usuarios, para controlar permisos. | Crear modelo de roles, implementar pantalla, validar permisos, registrar auditoría. |
Las historias de usuario son útiles, pero tienen límites. No siempre son suficientes para documentar todo un sistema.
Pueden ser insuficientes para:
En esos casos deben complementarse con otros artefactos.
Veamos una historia más completa:
Información complementaria:
La historia expresa valor; los detalles permiten implementarla y probarla.
Las historias pueden combinarse con prototipos, bocetos y conversaciones. Una historia puede motivar un prototipo para validar flujo o datos.
Por ejemplo, la historia "Como operador, quiero registrar un reclamo" puede acompañarse con un boceto de formulario y una lista de criterios de aceptación. Durante la revisión pueden descubrirse campos faltantes, reglas de prioridad o mensajes necesarios.
Esta combinación hace que la historia sea más concreta sin perder foco en la necesidad.
Al trabajar con historias de usuario, suelen aparecer estos errores:
Algunas buenas prácticas son:
Las historias de usuario son una herramienta práctica para expresar necesidades y orientar conversaciones. Su fuerza está en conectar rol, capacidad y valor de manera simple.
Pero su simplicidad también marca sus límites. Para que sean útiles en un proyecto real, deben acompañarse con criterios de aceptación, reglas, datos, restricciones y validación.
En el próximo tema estudiaremos los criterios de aceptación y la definición de terminado, elementos clave para saber cuándo un requerimiento o historia puede considerarse cumplido.