HISTORIAS DE USUARIO EN SCRUM
Dentro de la metodología á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 aparecer como <perfil>) que va a utilizar el
producto requiere 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
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).
1
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.
EJEMPLOS DE HISTORIAS DE USUARIO SCRUM
Veamos algunos ejemplos de historias de usuario scrum sobre una propuesta de plantilla con y sin criterios
de aceptación:
Ejemplo 1:
2
Ejemplo 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.
