Para que las historias de usuario sean efectivas, deben seguir una estructura simple y consistente que ayude a todos a entender tres cosas clave: quién se beneficia, qué se quiere lograr y por qué es importante. Esta estructura no es una regla rígida, sino una guía que ha demostrado ser increíblemente útil.
2.1. El formato clásico: “Como [rol], quiero [acción], para [beneficio]”
La estructura más conocida y utilizada para escribir historias de usuario fue popularizada por Mike Cohn y sigue este formato:
Como [tipo de usuario],
quiero [realizar alguna acción],
para [obtener algún beneficio o valor].
Desglosemos cada una de sus partes:
- Como [rol]: Esta parte describe quién es el usuario o la persona que se beneficiará de la funcionalidad. El "rol" no es un cargo (como "programador" o "gerente"), sino una descripción de la persona en el contexto del sistema (p. ej., "comprador registrado", "administrador del sitio", "visitante anónimo"). Definir el rol ayuda al equipo a empatizar con el usuario y a entender sus necesidades específicas.
- Quiero [acción]: Aquí se describe la meta o lo que el usuario quiere hacer. La acción debe ser concreta y observable. Es el "qué" de la historia de usuario. Por ejemplo, "iniciar sesión con mi correo electrónico", "filtrar los resultados de búsqueda por precio" o "descargar mi factura en PDF".
- Para [beneficio]: Esta es la parte más importante de la historia de usuario. Explica el "porqué" detrás de la acción. ¿Qué valor o beneficio obtiene el usuario al realizar esa acción? El beneficio justifica el desarrollo de la funcionalidad y ayuda al equipo a tomar decisiones. Si no hay un beneficio claro, quizás la funcionalidad no sea necesaria.
2.2. Importancia de expresar el valor de negocio
La cláusula "para [beneficio]" es el corazón de la historia de usuario. Sin ella, el equipo de desarrollo solo sabe lo que tiene que construir, pero no por qué es importante. Expresar el valor de negocio tiene varias ventajas cruciales:
- Facilita la priorización: El Product Owner puede comparar el valor de negocio de diferentes historias para decidir cuáles son más importantes y deben desarrollarse primero. Una historia que dice "...para cumplir con la normativa legal" probablemente tendrá más prioridad que una que dice "...para que el botón se vea más bonito".
- Inspira soluciones creativas: Cuando el equipo entiende el objetivo final, puede proponer soluciones alternativas que quizás sean más simples, rápidas o efectivas que la solución inicialmente imaginada. Por ejemplo, si el beneficio es "ahorrar tiempo al rellenar un formulario", el equipo podría sugerir autocompletar campos en lugar de simplemente rediseñar el formulario.
- Mantiene al equipo enfocado: Durante el desarrollo, el equipo puede usar el beneficio como una brújula para tomar micro-decisiones. Ante una duda técnica, pueden preguntarse: "¿Qué opción nos acerca más a lograr este beneficio para el usuario?".
2.3. Ejemplos bien y mal redactados
La forma en que se redacta una historia de usuario puede marcar la diferencia entre la claridad y la confusión. Veamos algunos ejemplos para ilustrarlo.
Ejemplo 1: Búsqueda de productos
Como usuario, quiero una barra de búsqueda para buscar.
¿Por qué está mal? Es redundante ("buscar para buscar"), no especifica el rol del usuario y no aporta ningún valor de negocio. El equipo no sabe qué tipo de búsqueda implementar.
Como comprador con prisa,
quiero buscar productos por su nombre,
para encontrar rápidamente lo que necesito sin navegar por categorías.
¿Por qué está bien? Define un rol claro ("comprador con prisa"), una acción específica ("buscar por nombre") y un beneficio evidente ("encontrar rápidamente").
Ejemplo 2: Exportación de datos
El sistema debe exportar los datos a CSV.
¿Por qué está mal? Esto no es una historia de usuario, sino un requisito técnico. No dice quién lo necesita ni para qué. Es una orden, no una descripción de una necesidad.
Como analista de marketing,
quiero exportar la lista de usuarios registrados a un archivo CSV,
para poder analizar los datos demográficos en una hoja de cálculo.
¿Por qué está bien? Identifica al usuario (analista de marketing), la acción (exportar a CSV) y el propósito (analizar datos), lo que da contexto y sentido a la tarea.