Las historias de usuario son una técnica ágil para definir la funcionalidad y los requisitos del producto. Se centran en contar una historia para una acción que realizará un usuario y cuál es la expectativa cuando tiene éxito. El concepto de historias de usuario está muy extendido, pero contar buenas historias puede ser bastante difícil.

Sin embargo, en los últimos años las historias de usuario han caído en desgracia, ya que son simplificaciones excesivas y carecen de empatía con el usuario.

Buenas noticias: ¡hay una forma mejor! Se llaman pepinillos, pero a diferencia del pepinillo, no están aquí para amargarte la vida. (A no ser que te gusten los pepinillos, supongo) 🥒.

TL;DR

Si tienes un poco de prisa, aquí tienes el resumen (aunque te animo a que sigas leyendo para acceder a las plantillas).

• Las historias de usuario se centran en el usuario, no en el producto.
• Esboce sus personajes para añadir contexto.
• Añade empatía a tus historias para comprender acciones y motivaciones.
• Pepinillos: una forma mejor de escribir historias.
• Utilice los pepinillos para centrarse en los resultados, no sólo en los productos.

¿Qué son las historias de usuario?

Las historias de usuario son descripciones breves y sencillas de una solución ideada por su equipo, contadas desde la perspectiva de la persona que realiza la interacción. Forman parte de una epopeya mayor que describe el problema real que hay que resolver y por qué lo estás resolviendo.

La palabra clave aquí es usuario, es decir, una historia de usuario se centra en el usuario, no en el producto.

Una historia de usuario suele centrarse en tres áreas:

• Como(quién)
• Quiero(qué)
• Para que(por qué)

Todo esto suele ir seguido de criterios de aceptación, que definen cómo se sabe si la interacción ha tenido éxito.

Quién: Utilizar personas para esbozar historias de usuario

Si todavía tiene que definir o entender a sus usuarios, entonces no debería escribir historias de usuario. En primer lugar, empiece con un poco de descubrimiento, trace un recorrido del cliente y cree personajes de usuario relevantes que le ayuden a definir mejor estas historias.

Un personaje puede ayudarle a comprender y contextualizar el «quién» de la historia de usuario, es decir, quién lleva a cabo esta interacción.

Esto es importante ya que inevitablemente tendrá diferentes segmentos de clientes, roles y permisos involucrados, por lo que definir esas interacciones para atender a esos diferentes tipos de usuarios es importante.

Qué: interacciones entre historias de usuarios

El «qué» de una historia de usuario se centra en la interacción en sí. Lo difícil aquí es asegurarse de que el «qué» se centra en lo que el usuario tiene que hacer, en lugar de en lo que el usuario quiere hacer, y aquí es donde la típica plantilla de historia falla un poco.

Para añadir un poco de empatía a la propia historia, es importante resaltar cómo podría sentirse el usuario al interactuar con una acción concreta.

Por ejemplo, nadie quiere introducir una contraseña complicada con mayúsculas, caracteres especiales y una longitud mínima, pero sabe que debería hacerlo. En este caso, es algo que el usuario está obligado a hacer.

Por qué: La razón de la acción de la historia de usuario

La tercera parte del modelo de historia de usuario es el «por qué», es decir, por qué el usuario quiere (o debe) llevar a cabo una acción determinada.

Volviendo a nuestro ejemplo anterior de introducción de contraseñas:

Como administrador, estoy obligado a crear una contraseña complicada, para que mi cuenta sea segura.

Ahora entendemos el quién, el qué y el por qué de la historia, pero hay un problema. Esto sigue careciendo de empatía y contexto, porque seamos sinceros, nadie quiere que las contraseñas complicadas sean un requisito, pero todos queremos cuentas seguras.

Al probarlo, el equipo de control de calidad se limitaba a comprobar si la contraseña era segura, no si el proceso resultaba frustrante para el usuario.

Introduzca la plantilla de historias de usuario Gherkin

Los pepinillos son una forma de añadir a las historias de usuario y dar un escenario completo que ayudará a los desarrolladores y probadores a entender tanto el resultado como la salida de una interacción de usuario en particular.

1. Scenario – el comportamiento que vas a describir
2. Given – el estado inicial del escenario
3. When – una acción específica que realiza el usuario
4. Then – un resultado comprobable, normalmente causado por la acción en When
5. And – esto continúa cualquiera de las otras tres operaciones si es necesario

Tomando el escenario de la contraseña descrito anteriormente:

1. Al establecer una contraseña (Scenario),
2. Given que soy administrador de una cuenta,
3. WhenIntroduzco una contraseña en el campo de contraseña,
4. ThenDeberían advertirme de los requisitos de contraseña,
5. And Debería poder hacer correcciones de inmediato,
6. Then que puedo crear una cuenta segura.

Ahora tenemos una visión completa de quién está llevando a cabo la acción específica, y cuáles son los requisitos para los criterios de aceptación, y el equipo sabe qué frustraciones potenciales puede haber para que puedan garantizar que el proceso fluya sin problemas.

Por lo general, el gestor del producto o el propietario del producto es el responsable de redactar las historias Gherkin, creando así una mejor comunicación entre el resto del equipo y asegurándose de que todo el mundo se centra en los resultados, no sólo en los productos.

¿Cuáles son sus formas favoritas de esbozar historias? Házmelo saber. ✌️