Los elementos de una buena historia de usuario

Las historias de usuario son una herramienta básica de un Product Owner. Su formato es sencillo y muy centrado en las expectativas del usuario. Se componen de la propia historia de usuario, además de los criterios de aceptación y en ocasiones un ejemplo de especificación.

La historia de usuario no es el santo grial que muchos creen, sino un contenedor que sirve como recordatorio de una conversación entre el Product Owner y el Development TeamUna historia de usuario es una promesa para mantener una conversación. Contrariamente a lo que mucha gente cree, el Product Backlog en Scrum está poblado por muchos tipos de requerimiento y solamente uno de ellos son las historias de usuario.

Es más acerca de la conversación que de la historia de usuario en sí misma. La conversación es lo que da las razones inherentes en la historia de usuario a lo que hay que hacer en el producto. La historia de usuario es únicamente un recordatorio de esa conversación.


3 Cs User Story

Las 3 C’s de la historia de usuario

Los elementos fundamentales de una historia de usuario son la Tarjeta (Card), la Conversación (Conversation) y Confirmación (Confirmation). Estos tres elementos son más importantes que cualquier detalle que pongamos en la historia de usuario en sí misma, y componen los elementos fundamentales de la historia de usuario. Sin ellos, la historia de usuario no está completa.

Tarjeta (Card): La tarjeta refleja los elementos más importantes de la historia de usuario. Expresa el valor que se quiere conseguir desde el punto de vista del usuario. Expresar un historia de usuario desde el punto de vista del desarrollador (As a developer I want…) o desde la organización (As the organisation I want to…) es una mala práctica que refleja la incapacidad de pensar en el valor para el usuario final.

Conversación (Conversation): Después de escribir la historia de usuario en la tarjeta, es necesario tener una conversación al respecto de su contenido. Hay que saber responder a cuestiones sobre el valor y sobre el resultado esperado de la implementación. Esta conversación puede suceder en cualquier momento; es habitual que se produzca durante el refinamiento del Backlog o el Sprint Planning.

Confirmación (Confirmation): La confirmación es un acuerdo que refleja que todas las personas implicadas, Product Owner y Development Team, entienden cuales son los elementos, valor y resultado esperado de la historia de usuario. Muchos equipos cometen el error de no tener esta confirmación, lo cual lleva a fricciones y problemas durante el Sprint Planning.

Relacionado
¿Es la deuda técnica un síntoma de mala gestión?

modelo de historia de usuario

Modelo de historia de usuario

Una historia de usuario generalmente sigue un patrón definido

As a... Persona para la que se cubre una necesidad
I want... lo que queremos que ocurra, por ejemplo una características o una funcionalidad
So that... el valor que obtiene la persona de la implementación de la característica o funcionalidad.

En la primera parte de la historia de usuario, es muy útil hacer referencia a usuarios de nuestro producto, usuarios que estén descritos y estudiados usando el modelo de User Personas, que toman una serie de rasgos de múltiples usuarios y construyen una persona ficticia que haga uso de la aplicación.

En la segunda parte de la historia de usuario, se explica lo que desde el punto de vista de la persona debería de suceder, sin entrar en descripciones técnicas. Una buena historia de usuario no tiene en cuenta lo que el sistema puede hacer, sino lo que el usuario quiere obtener.

Una historia de usuario está totalmente centrada en el usuario, y no en el producto o la organización.En la tercera parte, se expresa el valor que la persona quiere obtener, lo cual ayuda a entender y refinar, o incluso cambiar la forma en la que usuario obtiene el valor esperado.

Como se puede comprobar, las historias de usuario están totalmente alineadas con la expectativa del usuario, sin tener en cuenta capacidades o restricciones de nuestro producto. Una buena historia de usuario es aquella que está construida sobre datos reales, obtenidos de los propios usuarios.

Vanesa Tejada tiene una gran presentación sobre como escribir historias de usuario


acceptance criteria

Criterios de Aceptación

Los criterios de aceptación son los detalles de una historia de usuario, y ayudan a completar el patrón de valor expresado por la misma. Los criterios de aceptación incluyen los detalles que ayudan a visualizar la película completa y mejoran el entendimiento que el Product Owner, los Stakeholders y el Development Team tienen sobre lo que se va a realizar.

Relacionado
Management en el dominio de lo complejo

Los criterios de aceptación cumplen dos funciones: Clarificar el contexto en el que ocurre la historia de usuario y facilitar saber cuando están realmente terminadas.Los criterios de aceptación también son el medio por el cual el Development Team es capaz de saber cuando un ítem del Product Backlog está terminado, y ser capaces de testar los elementos de la historia de usuario en conjunto.

Unos buenos criterios de aceptación son claros, concisos, expresan una sola cualidad del ítem del Product Backlog y en la mayoría de ocasiones son redundantes, explicando desde múltiples puntos de vista cual es la imagen finalizada de la historia de usuario.

Además, pueden contener requerimientos no funcionales, si estos no están recogidos en la Definition of Done del equipo, como velocidad de la aplicación, concurrencia o elementos de seguridad que deben ser implantados para considerar la historia de usuario terminada.


specification by example

Specification by example

Otro elemento que puede resultar de ayuda en una historia de usuario es expresar los resultados deseados mediante un ejemplo, que ayude a entender al Development Team cual es el resultado deseado al implementar una historia de usuario.

No solamente es válido para Algoritmos, sino que también puede ser muy útil en el caso de implementación de diseños en un producto ya existente. Herramientas como InVision ayudan a los especialistas en UX/UI a diseñar flujos en una aplicación que posteriormente pueden ser implementados como especificaciones en el producto final, siendo uno de los criterios de aceptación que la UI del producto sea cómo la del diseño inicial.

También puedes leer más sobre Specification by Example en el blog de Martin Fowler.

Avatar for Jerónimo Palacios Vela

Publicado por Jerónimo Palacios Vela

Mi misión es ayudar a mejorar la profesión del desarrollo de software. Soy Professional Scrum Trainer de Scrum.org, Accredited Kanban Trainer de Lean Kanban y facilitador de LEGO® Serious Play. Vivo entre Berlín y Granada. Me encantan la vela y el Rugby

Suscribete a nuestra lista de correo

Suscribete a nuestra lista de correo

Recibe actualizaciones en la comodidad de tu bandeja de entrada. Un email a la semana. Sin Spam. Sin Trucos.

Suscripción con éxito

Shares
Share This