Las Historias de Usuario son una técnica nacida del mundo Agile y que trata de mejorar la interacción entre los usuarios y los desarrolladores. Nacidas de eXtreme Programming (XP), esta técnica reinventa la manera en la que “tomamos requisitos” y se considera esencial para mejorar el entendimiento entre el problema que pretendemos resolver y la solución que podemos aportar como Scrum Team.
Las Historias de Usuario y Scrum
Lo primero que debemos aclarar es que las Historias de Usuario son una técnica independiente de Scrum. Un Product Backlog no se compone de Historias de Usuario, sino de Item de trabajo, que pueden ser Historias de Usuario u otro tipo de requisito.
Entender este concepto es clave: aplicar Historias de Usuario forzadamente porque “es más Agile” es un error. Las Historias de Usuario aportan valor cuando sirven para mejorar la comunicación de los usuarios y afectados por tu producto con los desarrolladores del mismo.
Las Historias de Usuario no son una plantilla
Hace poco, me encontraba trabajando con un cliente y sus Product Owner y Analistas. Estábamos llevando la transición de un modelo tradicional, con requisitos escritos en documentos de más de cuarenta páginas, a un modelo de Historias de Usuario que describían comportamientos de nuestros usuarios.
En una de estas sesiones de mentoría, una persona me preguntó: “En las Historias de Usuario, ¿dónde pongo mis requisitos de siempre?”. En ese momento, tuvimos un debate sobre si las Historias de Usuario distaban mucho o no del modelo tradicional de toma de requisitos. La conclusión a la que llegamos es que si simplemente fueran un cambio de plantilla, cualquier equipo lo haría: tenemos que entender el cambio mental que representan.
Cambio de paradigma
A la hora de escribir Historias de Usuario, debemos entender el cambio de mentalidad que proponen. En los requisitos tradicionales, nos centramos en explicar cómo funciona nuestro producto, mientras que en las Historias de Usuario explicamos lo que hace el usuario con nuestro producto, para cumplir o resolver un problema.
Pongamos un ejemplo, imaginemos que tenemos que construir un menú con diferentes opciones para nuestro usuario. En un modelo tradicional, pintaremos el menú, las opciones, y las pantallas a las que nos dirigirá cada uno de los botones del menú. Por tanto, el documento será muy largo, porque habrá que describir cada pantalla en detalle. Con las Historias de Usuario, seguramente tengamos una Historia por cada opción del menú y nos centraremos en el objetivo para el que se pulsa. Por ejemplo:
COMO Usuario Autenticado
QUIERO ver mis ventas trimestrales
PARA entender cómo va mi negocio
A la hora de resolver esta historia, podremos crear un menú u otra opción. Lo bueno es que cada opción del menú anterior se convierte en muchos items de trabajo con los que podremos trabajar, pudiendo construirlos de manera iterativa e incremental ¡No tenemos que hacer todo el menú para entregar valor!
Hablar, elemento clave para construir software
Una de las claves para tener buenas Historias de Usuario es fomentar la conversación. Las Historias deberían ser escritas por el usuario final, para que describiera su problema, y resueltas por los Developers. Ahora bien, esto me ha ocurrido pocas veces. Aun así, la persona que escriba la historia (Product Owner, Analista, UX, cliente… ) debe tener una conversación con los Devs. La conversación nos sirve para aclarar conceptos, para entender mejor el problema y poder dar soluciones. Un ejemplo real que nos ocurrió hace años con un cliente:
COMO certificador autorizado
QUIERO exportar en excel todos los datos de la pantalla resultados
PARA poder tenerlos en un excel
Cuando el equipo vio esta historia, rápidamente levantaron la mano ¿Para qué necesitas este requisito? Bueno, es que quiero ordenar los resultados por distintos criterios y la pantalla no lo permite, por tanto, necesito que se exporte a excel. Entonces, la Historia de Usuario quedaría así:
COMO certificador autorizado
QUIERO exportar en excel todos los datos de la pantalla resultados
PARA poder ordenar los resultados por varias columnas
Una vez entendido el “Para”, podemos dar una mejor solución ¿Y si modificamos la pantalla para que permita ordenar los datos? De esta manera, nos ahorramos muchísimo trabajo, ya que exportar a excel es casi replicar los sistemas actuales.
COMO certificador autorizado
QUIERO ordenar los resultados de la pantalla por varias columnas
PARA entender mejor los datos
De esta manera, a base de conversaciones, entendemos mejor la necesidad de nuestro usuario y podemos dar la mejor solución.
Historias de Usuario Técnicas
Las Historias de Usuario técnicas no suelen tener mucho sentido. El objetivo de una historia no es describir el sistema sino describir al usuario. Ahora bien, en Scrum tenemos muchos más items, podemos combinar Historias con otro tipo de requisitos. Hace años me encontré la siguiente Historia de Usuario:
COMO usuario
QUIERO Sonar
PARA validar la calidad de mi código
¡Ningún usuario te ha pedido eso! Si necesitas instalar Sonar, pues entonces ponlo directamente:
Instalar Sonar versión XXXX
Criterios de Aceptación, ¡ponte en lo peor!
Los criterios de aceptación serían la cara “b” de una Historia de Usuario, donde especificamos los detalles de la misma. Vamos a describir una Historia y sus posibles criterios.
COMO cliente al corriente de pagos
QUIERO recibir una felicitación por mi cumpleaños
PARA mejorar la fidelidad del cliente
Imaginemos que se trata de una aplicación de móvil o del seguro que nos quiere felicitar por nuestro cumpleaños. Cada criterio de aceptación describe un escenario, generalmente, a mi me gusta empezar por el happy path, es decir, el escenario que escribe el éxito (pueden ser varios). Por ejemplo.
Escenario 1: Cumpleaños OK
DADO un cliente
Y ha pagado las últimas cuotas
CUANDO llega el día de su cumpleaños
ENTONCES recibe un email con una tarjeta personalizada*
*la plantilla del email se encuentra en XXXX
En este primer escenario, tenemos el caso en el que todo va bien. Pero… ¿qué ocurre si el usuario no está al corriente de pago? Depende, hemos decidido que, si se trataba de un usuario reciente, es decir, que pagaba desde hace menos de dos años, entonces sí recibe una felicitación y, además, se le invita a volver. Mientras que, si ha pasado más tiempo, entonces no le enviaremos nada. Esto genera dos nuevos escenarios.
Escenario 2: ya no paga, pero reciente
DADO un cliente
Y no paga las cuotas desde hace menos de dos años
CUANDO llega el día de su cumpleaños
ENTONCES recibe un email especial invitándole a que vuelva
Escenario 3: no paga hace mucho
DADO un cliente
Y dejó de pagar hace más de dos años
CUANDO llega el día de su cumpleaños
ENTONCES no se le envía el email de felicitación
Con esto, cubrimos varios casos de envío. Otro caso que se nos presenta, ¿qué ocurre si ese usuario es empleado? Si, por ejemplo, somos una compañía de seguros y regalamos el seguro a nuestros compañeros quizás el email sea diferente. Además, tenemos una política de que, el día de tu cumpleaños, se te regalan dos invitaciones de cine.
Escenario 4: empleado
DADO un empleado
CUANDO llega el día de su cumpleaños
ENTONCES se le envía el email corporativo de felicitación
Y se le envía dos invitaciones de cine
Todo esto requiere de mucha conversación, ¿esas invitaciones se pueden descargar en alguna plataforma o se envían adjuntas al email? Estos son los detalles que debemos aclarar con nuestros usuarios o peticionarios.
Imaginemos casos diferentes, ¿qué ocurre si la persona que recibe la felicitación nace el 29 de febrero? En ese caso, quizás el email sea diferente y lo reciba el día 28.
Escenario 5: 29 de febrero
DADO un usuario o empleado que cumple el 29 de febrero
Y no es un año bisiesto
CUANDO llega el 28 de febrero
ENTONCES se trata el día como si fuera su cumpleaños
Y se añaden unas líneas recalcando que este año no hay 29 de febrero
En este caso, estamos tratando dos posibles opciones que se podrían dar.
Consejos para escribir Historias de Usuario
A la hora de escribir historias, es clave entender muy bien el problema que queremos resolver. Es mejor muchas Historias de Usuario pequeñas que grandes historias. No existe una regla pero, si tenemos muchos escenarios, quizás debamos dividir la Historia en otras más pequeñas. También, si disponemos de pocas Historias de Usuario, deberíamos de pensar en todo aquello que podría fallar, porque detrás de los Criterios de Aceptación tenemos nuestras pruebas.
Las Historias de Usuario también nos sirven para desarrollar. Podemos tener test construidos a partir de los Criterios de Aceptación y, con ello, realizar un “desarrollo orientado a test”, lo que nos puede servir para todos los beneficios que Test Driven Development (TDD) propone.
Y tú, ¿cómo usas las Historias de Usuario?
Muy buen artículo, yo guío para que los Product Owner hagan las historias más o menos en la misma línea, sólo añado un detalle.
Cuando escriben los Criterios de Aceptación les digo que visibles a los Devs sólo dejen aquellos muy muy críticos que sin ellos no se entienda del todo el problema a resolver o el valor a aportar. El resto de Criterios de Aceptación que se los escriban ellos donde quieran, para, si en la conversación de manera natural no sale que no se les olvide mencionarlo.
La idea detrás de esta propuesta es favorecer lo máximo posible la conversación ya que sobre todo al principio, si les das muchos detalles a los Devs no hacen preguntas debido a la manera de trabajar de la que vienen.
Por otro lado, las Historias técnicas indicas que no tienen sentido, desde mi punto de vista sí lo tienen, lo que pasa es que se cae en el error de tratar de usar el mismo patrón y una Historia Técnica no debe usar el mismo patrón justo por lo que has explicado.
Lo dicho muy buen artículo 🙂
Un saludo,
Rubén Álvarez
Puede ser eh. Al final hay que generar confianza entre todos y, sobre todo, entendimiento. Es clave esa conversación para que les devs pasen de recibir requisitos a proponer soluciones