¿Qué es una historia de usuario (user story)?

Historia de usuario: definición y estructura

Una historia de usuario recoge un requisito en una frase: ¿quién quiere algo, qué debe ser posible y para qué? La forma clásica es «Como [rol], quiero [función], para lograr [beneficio]». El beneficio se incluye a propósito, porque muestra la importancia del requisito y si existen soluciones más sencillas.

Forman parte de la historia los criterios de aceptación, es decir, condiciones claras y comprobables que indican cuándo se da por cumplida. Los proyectos mayores se describen como «épica» y se dividen en historias individuales. Todas las historias se recogen en el backlog, que el Product Owner prioriza según el valor. Así todos ven qué viene a continuación y por qué.

Buenas historias de usuario: el principio INVEST

Como orientación sirve la sigla INVEST: independiente, negociable, valiosa, estimable, pequeña y comprobable (en inglés, Independent, Negotiable, Valuable, Estimable, Small, Testable). Una historia debe poder realizarse en pocos días y refinarse en el diálogo entre el departamento especializado y el desarrollo, en lugar de tratarse como un texto contractual rígido.

Los criterios de aceptación suelen formularse con el patrón «Dado – Cuando – Entonces»: dado un técnico con sesión iniciada, cuando abre un pedido, entonces ve la dirección, la persona de contacto y la lista de materiales. Estas frases pueden ser revisadas por especialistas y utilizarse después directamente como casos de prueba. Eso evita malentendidos entre el departamento especializado y el desarrollo.

• Nombrar el rol de forma concreta, en lugar de «el usuario» en general
• Recoger el objetivo y el beneficio en una frase
• Formular los criterios de aceptación de modo que se puedan comprobar
• Dividir la historia para que pueda terminarse en un solo ciclo
• No imponer una solución técnica cuando basta con el objetivo

Ejemplo práctico: una app para empleados en una empresa de fontanería

Una empresa de fontanería planifica una app para la obra. En lugar de una larga lista de funciones surgen historias como: «Como técnico, quiero registrar mis horas de trabajo directamente en la obra, para no tener que pasar notas a limpio por la tarde». O: «Como responsable de oficina, quiero ver qué pedidos se han terminado hoy, para facturar más rápido».

Al hablar de la primera historia se descubre que en algunas obras no hay cobertura. De ello surge un requisito propio: los datos también deben poder introducirse sin conexión. Sin la perspectiva del usuario, esto solo se habría advertido tras el lanzamiento, con el correspondiente trabajo de rehacer.

Límites, errores e implantación

Las historias de usuario no sustituyen a la documentación: para reglas complejas, interfaces o requisitos legales hacen falta descripciones adicionales. Los errores típicos son historias que encubren soluciones impuestas («Como usuario, quiero un desplegable …»), historias demasiado grandes, falta de criterios de aceptación e historias que el desarrollo redacta sin consultar a los usuarios.

Nano Concepts elabora los requisitos junto con sus departamentos especializados, los formula como historias de usuario con criterios de aceptación y los utiliza como base para la oferta, la ejecución y la aceptación. En proyectos mayores conviene reunir las historias más importantes en un breve taller conjunto. Así, todos los implicados saben qué se construye y cómo se mide el éxito.