¿Qué son las historias de usuario (user stories)?
Las historias de usuario son un recordatorio de la conversación que tenemos que tener. Y un recuerdo de la conversación que ya tuvimos.
La literatura habla de «las 3 Cs»:
1) Card (ticket o tarjeta): promesa o recordatorio de una conversación futura.
2) Conversación: sobre la historia de usuario y los detalles que implica.
3) Confirmación: definición de los criterios de aceptación, esto es, de los tests o verificaciones necesarias para que consideremos que la historia de usuario ha sido completada.
¿Para qué sirven las historias de usuario?
Frente a la creencia extendida, no sirven para documentar. Sirven para crear un contexto y entendimiento compartido, dentro del equipo y con los stakeholders.
Plantilla clásica
La plantilla o formato mas extendido para redactar historias de usuario es el siguiente.
As a <role/persona> (who?)
I want <behaviour> (what?)
so that <the value> (why?)
Ejemplo:
Como usuario-propietario
quiero poder listar mi coche en la plataforma
para así alquilarlo y generar un ingreso
¿Quién escribe las historias de usuario?
El Product Owner / Manager no tiene por qué ser quien redacte las historias de usuario. Aunque el Product Owner es responsable de la gestión y contenido del Product Backlog, las historias de usuario son un deporte de equipo. El Product Owner puede delegar.
Es más, si el Product Owner pasa la mayor parte de su tiempo escribiendo historias de usuario, mala cosa. Deben ser el resultado del trabajo de product discovery con clientes y usuarios.
Requisitos de una buena historia de usuario (“INVEST”)
Se suele decir que las historia de usuario deben ser INVEST:
Técnicas para trocear historias de usuario (“slicing”)
Lo importante a la hora de trocear las historias es que mantengan el valor para el usuario, que las desglosemos en vertical (por capas de funcionalidad), no de manera horizontal (por capas técnicas; diseño, back, front).
Algunas de mis técnicas de slicing preferidas son las siguientes.
1) Slicing basado en criterios de aceptación. Consiste en desgajar un criterio de aceptación que tenga identidad propia. Ejemplo: cuando el usuario cancela una operación, un criterio de aceptación podría ser que el usuario reciba una notificación. Esa notificación podría ser una historia de usuario separada.
2) Slicing basado en el CRUD (create, read, update and delete). Ejemplo: permitimos que el usuario pueda crear una solicitud, así como visualizarla y eliminarla. La edición de la solicitud la definimos como otra historia.
3) Slicing basado en datos, esto es, en los campos o tipos de información que el usuario puede introducir o consultar. Ejemplo: necesitamos que el usuario introduzca una serie de datos básicos (nombre, precio, tipo) y otros opcionales (matrícula, ubicación, teléfono), que consideramos en una historia adicional.
Estimaciones con historias de usuario
Lo primero que hay que resaltar es que las estimaciones son realizadas por los desarrolladores (programadores, testers, diseñadores, etc.), que son quienes van a hacer el trabajo de implementación. Las estimaciones no corresponden al Product Owner ni al Scrum Master.
La forma más habitual de estimar historias de usuario son los story points o puntos de historia. Son una medida relativa que comprende un conjunto de factores (esfuerzo, complejidad, riesgo); suele utilizarse la secuencia de Fibonacci simplificada (1, 2, 3, 5 y 8).
Otras formas de estimación son los días ideales, t-shirt sizing, same sizing, etc.