Buenas Historias de Usuario (User Stories) son un elemento clave en la metodología Agile – es a través de ellas que definiremos las funcionalidades de la aplicación que estamos creando.

La metodología Agile se basa en el principio de que las especificaciones de un proyecto deberían ser fáciles de entender y mantener. El sistema de gestión de proyectos Waterfall, que era el más común antes de la irrupción de la metodología Agile, era extremadamente complejo: IEEE Ansi 830 (1993, Rev 1998).

Los principios de desarrollo agile cambiaron esta práctica a favor de las historias de usuario (HdS). Las HdS no son tan exhaustivas como los requerimientos clásicos, pero la información que ofrecen tiene mucho más sentido, ya que una historia de usuario define una funcionalidad.

 

Cómo escribir buenas historias de usuario

Buenas historias de usuario deben ofrecer un actor, un objetivo, un contexto, una motivación y una forma de validarla – y debe permitir al product manager, al usuario y al desarrollador elaborar y discutir sobre ella de cara a poder crear el valor deseado.

Al desarrollar una historia de usuario debe quedar muy claro que estamos delante de una entidad viva, y que empieza con una propuesta inicial initial para abrir el diálogo entre cliente, manager y equipo de desarrollo. El hecho de que en muchas ocasiones este diálogo no tiene lugar no debe llevarnos a la falsa creencia de que una historia de usuario es inmutable durante todo el proyecto.

Los modelos de desarrollo basados en buenas historias de usuario son menos exhaustivas pero son una gran ayuda a la hora de definir el set de funcionalidades que se deben implementar desde el punto de vista del usuario, es decir, para que el resultado de nuestro desarrollo cumpla con las necesidades del cliente.

Preferiblemente, buenas historias de usuario deberían seguir el modelo INVEST:

  • “I” ndependiente – Independiente de otras historias de usuario
  • “N” egociable – Deben existir diálogos entre el cliente y el equipo de desarrollo, flexibilidad, no es un contrato cerrado
  • “V” aliosa – Cada historia de usuario debe añadir valor al producto
  • “E” stimable – El esfuerzo requerido por cada historia de usuario debe poder expresarse de manera más o menos objetiva (tiempo o puntos de historia – complejidad)
  • “S” mall (Pequeña)- Cada historia de usuario, idealmente, debería caber en una iteración (sprint). En caso contrario, se sugiere trocearla en partes más pequeñas
  • “T” esteable – Cada historia de usuario debe poder ser validada

Partes de una Historia de Usuario

Buenas historias de usuario están formadas por las siguientes partes:

  • Título
  • Descripción
  • Criterios de aceptación
  • Discusiones posteriores

Título

El título de una historia de usuario sigue la siguiente fórmula:

COMO <rol>

QUIERO <objetivo>

PARA <motivación>

Las historias de usuario definen una funcionalidad, pues en una sola frase debe quedar claro QUIEN (rol) hará una ACCIÓN (objetivo) para satisfacer una NECESIDAD (motivación)

Ejemplos de historias de usuario:

COMO usuario QUIERO poder buscar transacciones PARA poder detectar gastos innecesarios en mi cuenta durante cierto periodo de tiempo

COMO usuario QUIERO poder acceder a la agenda de enfermería PARA utilizar sus funcionalidades

El título de una historia de usuario debe mapear una funcionalidad de nuestro producto o software.

Cuando escribimos historias de usuario, es una buena práctica el usar personajes en vez de roles, ya que dan incluso más contexto. Por ejemplo:

COMO usuario QUIERO ser capaz de mostrar la lista de visitas PARA poder gestionar la llegada de pacientes y de salas de espera

vs:

COMO enfermera QUIERO ser capaz de mostrar la lista de visitas PARA poder gestionar la llegada de pacientes y de salas de espera

Con el simple cambio de “usuario” a “enfermera” estamos dando mucho más contexto a nuestra historia de usuario y la hacemos mucho más legible para cualquier persona sin background técnico.

Debemos recordar que el título de una historia de usuario debe mapear una sola funcionalidad de nuestro producto o software.

Descripción

La descripción de una historia de usuario ayuda a dar contexto a dicha historia. Ésta puede contener una pequeña explicación de los user flows, algunos casos de uso y casos extremos y, en general, cualquier explicación que ayude a comprender mejor el título. La descripción no es una biblia, y recordemos que una imagen es mejor que mil palabras: elementos como links a páginas con diseños o capturas de pantalla que ayuden a clarificar lo que se está expresando son siempre bienvenidos.

Una buena descripción contendrá, a ser posible, estos elementos:

  • Contexto: Proveer contexto de uso y aplicación para el desarrollador y el usuario, de cara a mejorar la comprensión del título.
  • Links a mockups o diseños: Resultan de gran ayuda de cara a comprender cómo mapear la funcionalidad de la historia de usuario en la aplicación.
  • Limitaciones: Elementos que todos los actores involucrados en la historia de usuario deben tener en cuenta (limitaciones de navegación y de diseño, o reglas de negocio.

Criterios de aceptación

Junto con el título, la parte más importante de una historia de usuario. Los criterios de aceptación son una serie de preceptos que validan la implementación de nuestra historia de usuario. Incluso a día de hoy hay equipos que no utilizan criterios de aceptación – En mi opinión, esto es un grave error. Los criterios de aceptación son fundamentales, pues:

  • Ayudan al desarrollador a implementar la tarea de forma correcta
  • En TDD los criterios de aceptación se mapean de manera directa sobre tests funcionales
  • Siguiendo TDD de forma estricta, la implementación debería empezar con estos criterios
  • Ayudan a equipo de QA de cara a dar el OK a considerar finalizada la historia de usuario
  • Los criterios de aceptación deben definir juntamente con el título la funcionalidad a implementar

El equipo de QA, idealmente, debería validar que se dan todos los criterios para dar el OK a subir a producción.

En general, los criterios de aceptación deben cumplir las características siguientes:

  • Atomicidad: Deben tener 2 resultados únicos: ÉXITO o FRACASO (no hay “éxito parcial” – un criterio de aceptación debe dar siempre verde o rojo).
  • No Ambiguos: Deben ser interpretados de única manera por N personas (algo como “el formulario debe tener un color alegre” no es válido. . .aunque cosas peores se han visto)
  • Verificables: Deben estar escritos de forma que el cliente los pueda verificar rápidamente
  • Completos: El grupo de criterios de aceptación debe incluir todos los requisitos funcionales

Ejemplo:

COMO usuario QUIERO acceder a la agenda de enfermería de forma segura PARA usar sus funcionalidades

Criterios de aceptación:

  • El nombre de usuario DEBE tener valor, en caso contrario se mostrará el mensaje de error pertinente
  • El nombre de usuario DEBE tener forma de email, en caso contrario se mostrará el mensaje de error pertinente
  • La contraseña DEBE tener valor, en caso contrario se mostrará el mensaje de error pertinente
  • El nombre de usuario DEBE existir en la base de datos en caso contrario se mostrará el mensaje de error pertinente
  • La contraseña DEBE coincidir con la que el nombre de usuario tiene asociada en la base de datos, en caso contrario se mostrará el mensaje de error pertinente

Si el usuario y la contraseña son correctos, el usuario podrá acceder a la aplicación.

Muchas veces estos criterios de aceptación pueden parecer triviales o innecesarios, pero ser riguroso con ellos mientras redactamos las historias de usuario es la mejor manera de desarrollar la funcionalidad

Discusiones posteriores

Alguien definió las historias de usuario como “una invitación a una conversa”. En un mundo ideal, con unicornios y arcoíris, tendríamos clientes estupendos con una idea súper clara de lo que quieren desde el principio y nos lo contarían con todo lujo de detalles sin dejarse nada en el tintero.

Pero eso no pasa. Nunca.

Una historia de usuario abrirá normalmente una conversación entre el equipo de desarrollo/PO y el cliente.

Normalmente, las historias de usuario no cambian a nivel conceptual, y son estas conversaciones las que las volverán más detalladas. Lo mismo ocurre con los grupos de criterios de aceptación.