Historias de Usuario

Historias de Usuario

En el post sobre el Product Backlog estuvimos viendo los distintos ítems o elementos o PBIs (Product Backlog Items) que incluye este artefacto Scrum. Y de entre todos ellos, las Historias de Usuario tienen un papel especialmente relevante ya que recogen las funcionalidades de negocio, y deben por tanto estar escritas por el Product Owner.

En este post profundizaremos en las Historias de Usuario Scrum. Veremos que son, su formato y cómo escribir buenas Historias de Usuario.

Adelante!!

Qué son las Historias de Usuario Scrum

Como ya he dicho, las Historias de Usuario Scrum son un tipo de ítem o elemento del Product Backlog. De hecho, son los PBIs más importantes del Backlog ya que contienen los requisitos funcionales del producto.

Cada Historia de Usuario deberá describir un requisito de negocio. Deberá estar escrita por tanto por el experto en negocio, o sea, el Product Owner.

Bueno, realmente el Product Owner puede delegar esa tediosa tarea, pero sea como fuere él es el responsable de ello. Por tanto, si las Historias de Usuario son un desastre no podrá echar balones fuera ni responsabilizar a nadie más que a él mismo.

El tamaño de las Historias de Usuario

Para que una funcionalidad pueda considerarse una Historia de Usuario, ésta debe tener un tamaño tal que pueda abordarse y terminarse completamente en un Sprint.

Por tanto, si tu Product Owner incluye en el Product Backlog una historia que en trabajo excedería el tiempo del que dispones en el Sprint, debes acordar con él que la subdivida en varias historias de usuario más pequeñas.

El motivo no es otro que si no haces esto no podrás terminar el desarrollo de tu Historia de Usuario y la dejarás a medias. Esto contradice la esencia de Scrum de entregar al final del Sprint un producto que aporte valor al cliente: no puedes dejar cosas a medias que no funcionen completamente, debes generar funcionalidad real.

Hay Product Owners que tuercen el morro cuando el Equipo de Desarrollo les viene con que deben subdividir una Historia de Usuario en varias. Suele tratarse de gente de negocio de la vieja escuela a los que estas exigencias de Scrum les parecen una tontería, básicamente por desconocimiento y porque subdividir historias es un trabajo complejo que no siempre les apetece realizar.

Así que te porfiarán alegando que para ellos no tiene sentido subdividir un requisito de negocio, que la funcionalidad es la que es y no es divisible y bla bla.

Ante eso no des un solo paso atrás, todo requisito de negocio puede subdividirse en requisitos más sencillos, se ponga como se ponga. De hecho, cuanto más sencillo y pequeño mejor.

Así que presiónale, chantajéale, sobórnale, haz lo que tengas que hacer, pero no admitas que tu Product Owner te endose Historias que no te será posible terminar en un Sprint.

Recuerda: en Scrum se entrega valor Sprint tras Sprint de forma iterativa e incremental desde lo más prioritario a lo menos prioritario. Por tanto, no dejes cosas a medias, las Historias de Usuario Scrum o se hacen completas o no se hacen.

Formato de una Historia de Usuario

Vamos a ver qué información debe reflejar cada Historia de Usuario del Product Backlog:

Identificador

Suele tratarse de un número autoincremental o del código de proyecto seguido de dicho número.

Por ejemplo, para el ejemplo del comercio electrónico, un posible identificador podría ser MITIENDA-123.

Sea como fuere deberá de tratarse de un código único para esa historia.

Nombre

Descripción corta de dicha historia. Ejemplo:

Mostrar contenido del carrito.

Descripción

Requisito funcional al que hace referencia dicha historia. Ejemplo:

Como cliente quiero poder pulsar sobre el icono carrito para poder ver el contenido de éste y que se me muestren por pantalla todos los productos que tengo seleccionados.

En la descripción se incluirá, si es necesario, los criterios de aceptación que completen dicho requisito funcional.

Estimación

Consistirá en un número de puntos de historia, o tiempo, o talla o lo que utilices para estimar y que representará el esfuerzo en desarrollar esa historia.

Prioridad

Puedes añadir a la Historia un número que indique su prioridad, por ejemplo, una historia con prioridad 15 es más prioritaria que otra con prioridad 4.

Sin embargo, sabiendo que un Product Backlog es eminentemente una pila, este campo no es necesario especificarlo directamente ya que la posición del ítem en el Backlog determinará su prioridad.

Por ejemplo, si estás utilizando una Excel para reflejar tu Product Backlog, los elementos que se muestres en las primeras filas de la Excel serán más prioritarios que los de las filas de más abajo.

Si usas una herramienta como Jira será tres cuartas de lo mismo: de arriba abajo podrás ver los ítems de más prioritarios a menos.

Además de estos campos básicos, una historia puede contener más información, casi tanta como se te ocurra:

  • Tipo de ítem o issue type: el PBI es una historia de usuario, una historia técnica, un bug, etc. En el caso de una historia de usuario su tipo de ítem será ese, historia de usuario o user story.
  • Épica a la que pertenece.
  • Sprint en el que se aborda.
  • Estado: TO DO, IN PROGRESS, BLOCKED, IN TEST, DONE, etc
  • Release a la que pertenece.
  • Comentarios y observaciones.
  • Nombre de las subtareas, si es que tiene.
  • Forma de probar la historia de usuario: descripción de los pasos que hay que dar en el aplicativo para poder probar la funcionalidad reflejada en dicha historia.
  • Nombre del creador de la historia (normalmente el del Product Owner).
  • Fecha de creación.

Estos campos no son exclusivos de una historia de usuario. Podemos extrapolarlos a otros PBIs, como historias técnicas o bugs.

Cómo escribir buenas Historias de Usuario

La descripción de una Historia de Usuario debe deberá reflejar las funcionalidades necesarias en el producto, siempre desde la perspectiva de la persona que la solicita, normalmente un usuario o cliente del sistema.

Se escriben con el siguiente formato:

Como <rol> quiero <acción/qué> para <propósito/por qué>

Por ejemplo:

Como cliente quiero poder clickar en el carrito de la compra de mi cuenta para poder ver los productos que tengo seleccionados

Una vez tenemos esto, si queremos mayor nivel de detalle podemos incluir los criterios de aceptación que necesitemos, pero procura que la descripción sea lo más corta y simple posible.

Para crear Historias de Usuario Scrum debemos tener presentes los atributos INVEST. El acrónimo INVEST hace referencia a: Independiente, Negociable, Valiosa, Estimable, Corta (Short) y Testeable.

Veamos en más detalle.

Atributos INVEST de las Historias de Usuario

Una Historia de Usuario debe presentar las siguientes características:

Independiente

No debe presentar dependencias con otras historias que pudieran impedir su desarrollo.

Negociable

Debe existir espacio para la negociación entre Product Owner y el Equipo de Desarrollo a la hora de establecer los detalles de la historia.

Valiosa

Debe aportar valor al cliente. Hablando en plata: no pierdas tiempo en desarrollar una inutilidad.

Estimable

Puede ser estimada por el DevTeam (por ejemplo, en tamaño relativo o puntos de historia).

Corta

Debe tener un tamaño que permita poder terminarla durante el Sprint. Si te topas con una Historia más grande que eso exige al Product Owner que la subdivida en varias Historias más pequeñas.

Testeable

La historia en su descripción debe contar con la información suficiente como para poder ser probada.

Reflexión final

La creación de las historias de usuario del Backlog es una de las cosas más importantes y delicadas a las que se enfrentará el Product Owner.

La calidad del Product Backlog depende de la calidad de sus historias, así que tanto el Product Owner, como también el Scrum Master asistiéndolo y supervisándolo, deberán hacer hincapié en esta labor. Cualquier esfuerzo que se dedique a tener una buena colección de historias estará bien invertido.

Y recuerda seguir siempre los criterios de los atributos INVEST. Si los sigues fielmente tendrás grandes posibilidades de que tu Backlog refleje correctamente y sin ambigüedades la lógica de negocio de tu producto y se lo estarás poniendo fácil a tu Equipo de Desarrollo.

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario