Historias de usuario vs Casos de uso

¿Pero no son lo mismo? Cuando uno empieza en el mundo agile, y ve por primera vez las historias de usuario, lo primero que piensas es: «pero si estos son los casos de uso de toda la vida». Y la respuesta es un si pero no, ya que aunque en ciertos puntos son parecidos, existen diferencias entre ellos.

Las historias de usuario están centradas en el resultado y beneficio de lo que estás describiendo, mientras que los casos de uso están más centrados en cómo el sistema actuará.

Similitudes

  • Ambos están escritos desde la perspectiva del usuario, buscando cómo usar el producto.
  • Los dos contienen el objetivo y criterio de aceptación.
  • Tienen elementos comunes: un actor, flujo de eventos y condiciones a conseguir.

Diferencias

  • Los casos de uso llegan a más detalle en la documentación.
  • Las historias de usuario dejan detalles sin especificar, para provocar conversaciones en las reuniones scrum.
  • Pequeños incrementos con feedback en lugar de algo más detallado y cerrado como serían los casos de uso.

Qué son las historias de usuario

Las historias de usuario son breves descripciones, desde el punto de vista del usuario, que recogen qué hace o necesita hacer el usuario.

Se centran en lo que el usuario necesita, en lugar de lo de que sistema debe entregar. Lo cual da lugar a futuras conversaciones sobre lo que el sistema debe hacer para cubrir dicha necesidad del usuario, fomentando un entorno agile.

Todos conocemos el concepto de escribir las historias de usuario como tarjetas siguiendo la estructura de:
«Yo como <role>, <quiero> <para>.»

Pero las historias de usuario son mucho más. Como comenté antes, se suelen dejar con poco nivel de detalle para fomentar discutir sobre ellas, por lo que las conversaciones entre los distintos stakeholders son parte de ellas. Así como el criterio de aceptación, que nos valdrá para darla por hecha o no, asegurando un nivel en los desarrollos, el llamado Definition of Done (DOD).

Qué es un Caso de Uso

Son una forma de describir requerimientos funcionales usando el punto de vista del actor.

Captura las distintas formas en las que el usuario y el producto interactuan para conseguir un objetivo.

Especifica cómo el usuario interactúa con el producto y cómo el producto responde las a las acciones del usuario.
Un caso de uso tipo suele incluir:

  • Descripción
  • Precondición
  • Postcondición
  • Flujo básico (si va todo bien)
  • Flujos alternativos (caminos si no todo ha ido correctamente)

¿ Uno u otro ?

Sé que nos movemos normalmente en entornos agile, y que queda mucho más «cool» trabajar con historias de usuario que con casos de uso. Pero particularmente los casos de uso me ayudan a tener una visión más global de la funcionalidad del producto, saber qué es lo que tiene que hacer y cubrir. Mientras que las historias de usuarios son más útiles a la hora de pelotear con los distintos stakeholders y saber exáctamente qué es lo que ellos quieren.

Así que ni uno ni otro, los dos 🍻