Dentro de la metodologías ágil (agile) existe un elemento sumamente importante para aplicar en ellas, especialmente en Scrum; nos referimos a las historias de usuario. En esta entrada vamos a explicar qué son y cómo hacerlas, además de dejaros una plantilla que podréis descargar, usas y modificar según vuestras necesidades.

¿Qué son las Historias de Usuario Scrum?

Las historias de usuario Scrum son una herramienta con la que podremos tratar cualquier aspecto necesario para la creación de productos (utilizada especialmente el desarrollo de software). Son, esencialmente, pequeñas descripciones de los requerimientos de un cliente.

El formato para las historias de usuario Scrum se basan en una regla de tres palabras:

  • Como <rol>
  • Quiero <eventos>
  • Para <funcionalidades>

De manera que el <rol> que escojamos (en algunos sitios puede aparece como <perfil>) que va a utilizar el producto requiere de que ocurra una <evento/acción>, porque desea cubrir una <funcionalidad>. Como veis, breve y concreto. Además, deben usar un lenguaje sencillo, no técnico, puesto que la finalidad de las mismas es ser lo más claras y directas posibles (y ponernos muchas veces un <rol> de usuario o cliente sin conocimientos técnicos). Describen el resultado deseado sin entrar en detalles (que se agregarán más tarde).

Formato para las historias de usuario Scrum
Formato para las historias de usuario Scrum

Un ejemplo de historia de usuario en scrum: Como usuario de un videojuego online quiero ordenar los objetos desbloqueables del juego como gratuitos o de pago para escoger aquellos gratuitos.

Aspectos más importantes de las Historias de Usuario: PARA y QUIERO

Los aspectos más importantes de las historias de usuario en scrum son el PARA y QUIERO. El PARA es siempre la <funcionalidad> que se quiere cubrir, por lo que puede resultar fácil confundirla con el QUIERO, que es dónde debemos describir cuál es la intención y no las funciones que utiliza, es decir, ¿qué es lo que se intenta conseguir realmente?, ¿cuál es el objetivo del usuario?

Así, es labor de todo el equipo buscar las funcionalidades reales que hay por detrás para poder encontrar la mejor solución posible y para ello es necesaria una buena redacción de las historias de usuario.

Las 3 Cs de las Historias de Usuario

Podemos decir que las historias de usuario se basan también en las 3Cs: Card, Conversation y Confirmation (Tarjeta, Conversación y Confirmación).

Card de tarjeta

Comenzaremos por usar una tarjeta (puede ser una cartulina tamaño cuartilla o un post-it) en la que escribiremos esa regla de las tres palabras. Así cada historia de usuario estará contenida en una tarjeta, que podremos mover en el backlog del Scrum según nos convenga, según la prioridad o por módulos temporales, etc.

Conversation para explicar mejor la Historia de Usuario

Hemos dicho que las historias de usuario son una frase sencilla y concisa, sin embargo, eso no impide que se pueda abrir un diálogo (conversación) entre todos los  miembros del equipo. De hecho esta conversación se debe llevar a cabo para explicar mejor la propia historia de usuario y conseguir objetivos como:

  • Detallar a mayor nivel como se realizará la solución.
  • Clarificar aspectos de valor, funcionamiento y técnicos.
  • Resolver las dudas que aparezcan.

Estas conversaciones llevarán a alcanzar acuerdos sobre los distintos puntos tratados, que quedarán reflejados en los criterios de aceptación y que nos permitirán validar cuando una historia de usuario está terminada.

Confirmation de los Criterios de Aceptación

Como ya hemos dicho, de la conversación obtendremos los criterios de aceptación, es decir, la confirmación. Se trata de criterios claros y específicos que todo el equipo debe comprender y que permitirán avaluar en el futuro si la implementación que se está desarrollando o las pruebas que se realicen están terminadas.

¿Quién estima las historias de usuario y quién las hace?

Las historias de usuario la estima el Product Owner (Dueño del Producto), que es quién identifica la necesidad y la puede priorizar y quien debe asegurarse que el producto backlog esté siempre actualizado y priorizado con historias de usuario.

Y, aunque, normalmente, es también el encargado de escribir las historias de usuario, lo cierto es que una vez metidos dentro del proyecto, otros miembros del equipo pueden escribir historias de usuario, siempre manteniendo en mente que será el Product Owner el encargado de incluirlas o no el backlog.

▷ Plantilla modelo de Historias de Usuario

A continuación os vamos dejar una plantilla modelo de historias de usuario en Scrum, que podréis descargar y editar según vuestras necesidades, pero recordad que cuanto más sencillo mejor, para que sea flexible a la hora de crear las historias de usuario.

Podréis integrar esta plantilla en vuestro Google Drive, de manera que la compartáis entre el equipo de desarrollo, el Producto Owner y el Scrum Master, puesto que uno de los requisitos de las historias de usuario es que deben ser visibles por todos los integrantes del equipo.

Ejemplos de historias de usuario scrum

Veamos algunos ejemplos de historias de usuario scrum sobre la plantilla que os hemos dejado más arriba, con y sin criterios de aceptación:

Ejemplo 1:

Historias de usuario scrum ejemplo 1

Ejemplo 2:

Historias de usuario scrum ejemoplo 2

Tips para conseguir buenas Historias de Usuario Scrum

Ahora que ya sabemos lo que son las historias de usuario, aquí van unos consejos para aseguraros de que sean buenas:

  • Las historias de usuario deben ser independientes entre sí, de manera que se puedan llevar a cabo en el orden que más convenga según las prioridades qu establezca el Product Owner en el backlog del producto.
  • Su tamaño debe ser pequeño para que puedan asumirse en un sprint y, si es posible, asumir varias dentro del mismo sprint (si son muy grandes, estaríamos hablando de lo que se conoce como un epic, que normalmente está formado por varias historias de usuario de menor tamaño).
  • Han de ser estimables, es decir, el equipo de encargado de ellas debe ser capaz de estimar el esfuerzo que supone realizarla.
  • Se deben poder negociar entre el Product Owner y el equipo, de manera que se puedan establecer los límites adecuados (aquí entra en juego la Conversación de la que hablábamos más arriba).
  • Tienen que tener valor para el usuario, recordad que el PARA es fundamental; la funcionalidad debe ser entendida por todo el equipo.
  • Se debe poder testear para confirmar que su implementación es correcta, es decir, cumplir con los criterios de aceptación establecidos.
  • Recoge comentarios de los clientes, no te hará falta “inventar” historias de usuarios si las recoge del feedback que ofrecen tus clientes.

En definitiva, las historias de usuario serán las tareas que conformarán el backlog (o pila de producto)  en nuestro método ágil, el Product Owner será el encargado de gestionarlas, estimarlas y también de escribirlas, aunque eso no excluye al resto de miembros del equipo. Nos sirven para dividir tareas más grandes en tareas más pequeñas y manejables, que podrán completarse en un sprint o iteración. Y además, son una herramienta que podremos usar para fomentar y mejorar la comunicación de todos los miembros del equipo, puesto que una de sus características esenciales es la conversación y el llegar a acuerdos para confeccionar los criterios de aceptación.

Si vas a empezar una metodología agile, no te puedes olvidar de las historias de usuario.