Tanto si conoces como no el término “Historia de Usuario”, espero ayudarte con este artículo a entender su concepto, qué papel juegan dentro de las metodologías y frameworks ágiles y cómo escribir buenas historias de usuario.

¿Qué es una Historia de Usuario?

El primer paso lógico es entender el concepto. De forma sencilla se puede decir que las “historias de usuario” son a las metodologías y frameworks de gestión ágiles, lo que los “requisitos” a la gestión tradicional de proyectos.

En el ámbito de la agilidad, las historias de usuario son lo más parecido a los requisitos del producto, servicio, sistema o proyecto que se quiere diseñar, construir y poner en marcha.

Tal como las define Mike Cohn, las historias de usuario son: “descripciones breves y simples de una característica contada desde la perspectiva de la persona que desea la nueva capacidad, generalmente un usuario o cliente del sistema.”

Asimismo, Cohn nos explica que abarcan o contienen tres aspectos:

  • Una descripción de la historia, que se usa para la planificación y como recordatorio
  • Conversaciones sobre la historia que sirven para ir extrayendo sus detalles
  • Tests que documentan los detalles y permiten validar que la historia está terminada

El origen de las historias de usuario se remonta a la metodología de desarrollo ágil XP (eXtreme Programming) formulada por Kent Beck en 1999. Se utilizan de forma habitual en todas las metodologías de desarrollo y frameworks ágiles para escribir los requisitos y las pruebas de validación, así que, recomiendo te familiarices con ellas.

Requisitos Tradicional vs Agile: una cuestión de enfoque

Las historias de usuario en las metodologías ágiles nos ayudan a cambiar el enfoque tradicional de la “toma de requisitos” y la “especificación funcional”.

En el enfoque tradicional, las tomas de requisitos se realizan como un proceso unidireccional, en el que no participan todos los actores necesarios. Además, no hay una validación hasta el final, con las pruebas y validación del cliente.

Tal como muestra la figura siguiente, con frecuencia, algún representante del usuario final designado por el “Cliente” le cuenta lo que quiere o necesita – incluso cuando no lo sabe exactamente – a un analista funcional y/o jefe de proyecto designados por el “Proveedor”.

Figura: toma de requisitos tradicional

¿El resultado? Un extenso documento con una larga lista de requisitos funcionales y de características técnicas, tales como lenguajes, frameworks y tecnologías a utilizar, sistemas a integrar, requisitos de escalabilidad, rendimiento, alta disponibilidad, etc.

¿El problema? Al inicio creeremos tener un documento que define perfectamente cuál debe ser el comportamiento y prestaciones del proyecto/producto. Al final, posiblemente no será así y habrá que acometer un buen número de cambios, incrementando plazos y costes.

Necesito una solución:

Para solucionar los aspectos negativos del enfoque tradicional, las metodologías ágiles nos ofrecen otra forma de abordar los requisitos mediante las historias de usuario.

Ya no se trata de escribir una larga lista de requisitos funcionales y características técnicas sino de hablar de las funcionalidades deseadas y fomentar la conversación y el análisis compartido entre los que necesitan usar el producto/servicio y los que han de diseñarlo y construirlo.

¿Cómo escribir Historias de Usuario?

Las historias de usuario suelen escribirse siguiendo un formato muy sencillo:

As a < type of user >, I want < some goal > so that < some reason >

Si lo detallamos un poco más en español, con su título y sobre una tarjeta:

Figura: plantilla historia de usuario

Pongamos un ejemplo sencillo:

  • Como    usuario de la aplicación móvil del banco
  • Quiero  visualizar mi posición global en la página de entrada
  • Para      saber si dispongo de saldo suficiente nada más acceder sin navegar por menús

Las historias de usuario a menudo se escriben en tarjetas de tipo “post-it” para poder pegarlas sobre algún tipo de tablero o panel en las paredes. De este modo se facilita el debate sobre cómo organizarlas y la planificación. Al tratarse de tarjetas de un tamaño reducido, no se puede escribir mucho, lo que obliga a pensar y resumir muy bien el objetivo.

Lo que se persigue es cambiar el enfoque de “escribir” a “fomentar la conversación” sobre requisitos y características. Estas conversaciones en las que se analiza y discute en común son mucho más importantes que cualquier especificación funcional escrita.

Épicas vs Historias

Las historias de usuario pueden crearse con distintos niveles de detalle. Podemos escribir historias que comprendan un gran número de funcionalidades relacionadas. Este tipo de historias de gran tamaño suelen denominarse “Épicas”. Volviendo a nuestro ejemplo de una aplicación de banca para móvil, podríamos tener una épica que fuese:

  • Como    usuario de la aplicación móvil del banco
  • Quiero  programar una transferencia periódica
  • Para      poder pagar una cantidad mensual, semanal, etc.

Las épicas son normalmente bloques funcionales demasiado grandes como para que equipo ágil pueda completarlos en una iteración, esto es, dentro de un sprint en Scrum. Por eso es necesario dividirlas en historias de usuario más pequeñas.

Criterios de Aceptación

Los criterios de aceptación son una parte fundamental de las historias de usuario, puesto que permiten definir las pruebas a realizar para poder verificar su aceptación, esto es, que una vez terminada, la historia de usuario entrega el valor esperado por el Product Owner.

Los criterios de aceptación deben indicar en un lenguaje claro, conciso y en términos de negocio las condiciones que deben cumplirse para que una historia se acepte como terminada. Podríamos extendernos bastante en este punto, pero da para otro artículo.