Guía sobre las historias de usuario

¿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:

  • Independiente: querremos eliminar las dependencias entre historias, en la medida de lo posible.
  • Negociable (y negociada): un exceso de detalle puede hacernos pensar que no hay margen de negociación, que no hay necesidad de tener la conversación. 
  • Valiosa para usuarios o clientes: evitemos escribir historias en términos de valor para el desarrollador.
  • Estimable: queremos poder estimar qué esfuerzo implica completarla.
  • Pequeña: han de tener el tamaño “suficiente” y poder ser completadas en un Sprint o antes.
  • Testeable: con criterios de aceptación que permitan verificar que se ha implementado con éxito.

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.

Cuando estés listo, podemos ayudarte de 3 formas:

  1. 1. Únete a nuestra Newsletter, Líderes de Producto: recibe contenidos exclusivos sobre Agile y Product Management.
  2. 2. Apúntate a una de nuestras formaciones: cursos intensivos para Product Owners/Managers y Scrum Master/Agile Coaches, en directo e impartidos por nuestros especialistas.
  3. 3. ¿Quieres formar a tu equipo? Hacemos formaciones “privadas” para empresas, con las que transformar vuestra forma de trabajar. Somos especialistas en Scrum y Product Management.
Comparte este post

Publicado por Sergio Rodríguez

Especialista en producto y Professional Scrum Trainer acreditado por Scrum.org. He sido Product Manager, Head of Product y consultor de producto en empresas como Liftshare, Cardmarket o Wave.

Subscríbete a nuestro Newsletter

Únete a cientos de lectores de Líderes de Producto para recibir historias, consejos y recursos sobre Product Management y Scrum.