Plantilla para las historias de usuario

Plantilla para las historias de usuario

Las historias de usuario han ganando terreno en la representación de los requisitos frente a los casos de uso, usado en los patrones tradicionales de la ingeniería del software, durante los último años. Si te interesa conocer las diferencias entre las historias de usuario y los casos de uso puedes leer este post.

Una historia de usuario es una representación de un requisito escrito en una o dos frases utilizando el lenguaje común del usuario. (Wikipedia)

El uso de las historias de usuario se recoge en la gran mayoría de frameworks ágiles, como por ejemplo Scrum o extreme programming (XP), para la definición de lo que se debe construir en el proyecto.

Los tres elementos de las historias de usuario son:

  • Tarjeta (Card): Describe los elementos más importantes de la historia de usuario. Se centra en el valor que se persigue desde el punto de vista del usuario.
  • Conversación: Toda historia de usuario debe ir acompañada de una conversación por parte del equipo. En Scrum los momentos ideales para la conversación es durante el refinamiento del backlog, el sprint planning o en algún momento después de la daily.
  • Confirmación: Consiste en el acuerdo de todas las partes (cliente, product owner, equipo de desarrollo) sobre cuales son los elementos, el valor y el resultado esperado de la historia de usuario en cuestión.

Puedes descargarte aquí la la plantilla para definir historias de usuario (aquí si prefieres en Keynote).

Plantilla historia de usuario

Formato de las historias de usuario (Tarjeta)

En las historias de usuario no se expresan descripciones técnicas. Se escriben bajo el punto de vista del usuario, sin tener en cuenta qué hace hoy el sistema en el qué se trabaja. Es muy importante que no sólo se describa qué se quiere sino también cuál es el motivo.

En el desarrollo de software es imprescindible conocer dónde reside el valor del producto. Las historias de usuario nos permite saber cuál es el valor buscado. Conocer bien en qué consiste este valor permite al equipo entender bien el requisito y su necesidad para poder ayudas a refinar e incluso mejorar la forma en la que el usuario obtendrá el valor esperado.

Se recomienda redactarlas en una frase que responde a estas tres preguntas:

  • ¿Quién se beneficia?
  • ¿Qué se quiere?
  • ¿Cuál es el beneficio

La sintaxis de la frase es la siguiente:

Como [rol]  quiero [algo]  para poder [beneficio].

Esta frase no es suficiente para describir una funcionalidad, pero éste no es su único objetivo. Las historias de usuario nos deben generar conversaciones profundas acerca de la funcionalidad. Estamos ante una herramienta de comunicación muy potente, que da la fuerza al equipo para interactuar e involucrarse en la definición del proyecto.

Una historia de usuario es una promesa (Conversación)

Entender las historias de usuario como una simple frase escrita por el product owner y bajo una sintaxis definida es no haber comprendido su auténtica fuerza. Debemos entender que una historia de usuario es una promesa.

Se trata de una promesa de mantener una conversación acerca de la funcionalidad que describe. Nos sirven para empezar un diálogo entre todos los miembros del equipo. Esta es la verdadera fuerza de las historias de usuario, el poder de comunicación.

Las conversaciones que tenemos nos permiten detallar a mayor nivel cómo se realizará esa funcionalidad descrita en la tarjeta. Estas conversaciones nos deben servir para clarificar todos los aspectos y dudas que podamos encontrarnos.

Si formas parte de un "equipo" que no mantiene dichas conversaciones debes empezar a trabajar por el cambio. Hablar de las historias de usuario es necesario para trabajar coordinadamente bajo el mismo objetivo: aportar el máximo valor posible en cada iteración. 

El objetivo principal de la conversación es conseguir acuerdos en cada uno de los puntos hablados, de este modo evitaremos encontrarnos en discrepancias futuras. En las conversaciones deben participar todos los puntos de vista posibles: desarrollo, producto, operaciones, clientes... Cuantos más podamos participar mayor será el entendimiento y acordar qué significa una historia de usuario. Es así como encontramos dónde reside el valor.

La comunicación es uno de los grandes problemas de las organizaciones. Los errores que se generan por una mala comunicación son de las grandes ineficiencias de las empresas, también en el desarrollo de software. En este aspecto son (trágicamente) un clásico las discusiones entre un desarrollador y algún cliente interno de la empresa (tester, operaciones, product owner, key account...) acerca de qué significaba un requerimiento una vez ya está programado o incluso en producción.

Discutir qué significa una funcionalidad una vez ya programada es lo contrario a: trabajar en equipo, tener una buena comunicación, estar motivado por el trabajo o considerarse ágil.

Si quieres saber más acerca de cómo las historias de usuario nos ayudan a motivar al equipo puedes leer este post, en el que se plantea que a los humanos nos gustan las historias y no las tareas.

Los criterios de aceptación (Confirmación)

Las historias de usuario se completan con unos criterios de aceptación. Estos criterios nos sirven para confirmar la implementación que se está desarrollando, las pruebas a realizar y cómo verificar de que se ha completado el trabajo.

De este modo detallamos la historia de usuario. Nos ayudan a entender mejor el trabajo a realizar y permiten al product owner definir los requerimientos de cómo debe comportarse el sistema ante los distintos eventos generados.

Como escribe Jerónimo Palacios, los criterios de aceptación cumplen principalmente dos funciones:

  • Clarificar el contexto en el que ocurre la historia de usuario
  • Facilitar saber cuando una historia de usuario está realmente terminada

Los criterios de usuario también tiene su sintaxis definida:

Escenario [número] - [Título del escenario (opcional)]: En caso que [contexto] y adicionalmente [contexto], cuando [evento], el sistema [resultado / comportamiento esperado].

Definimos el contexto como una descripción precisa sobre las condiciones que desencadenan el escenario previsto. El evento representa la acción realizada por el usuario en el contexto descrito. La representación de la situación (contexto + evento) nos permite describir cual es el resultado deseado. Entendemos como resultado el comportamiento esperado del sistema bajo esta situación.

Otra función que nos ofrecen los criterios de aceptación es evaluar si es necesario dividir la historia de usuario. Un error frecuente en la definición de requerimientos es construir historias de usuario demasiado largas. Podemos aceptar la recomendación de subdividir una historia de usuario que cuente o necesite más de 4 criterios de aceptación.

Para mejorar la comunicación en la toma de decisiones es interasante conocer el planteamiento de Toyota, tomar las decisiones lentamente e implementarlas rápidamente.

Conclusiones

Las historias de usuario son un elemento clave para potenciar la participación del equipo en la toma de decisiones sobre el trabajo a realizar. Un equipo auto-organizado es capaz de decidir sobre la evolución que seguirá el producto, bajo la seguridad de avanzar en la dirección deseada.

Un problema típico de muchos equipos, en este caso seguramente sería mejor decir grupo de trabajo, es la comunicación. No generar conversaciones sobre las historias de usuario es un problema. Uno no se puede quejar de que las historias de usuario no son suficientemente completas o concretas y no generar una conversación para detallarlo. El punto de partida es la conversación para generar acuerdos.

Ante una historia de usuario levántate, junta a los involucrados, empieza una conversación y generad acuerdos.

Product owner, developers, clientes, usuarios... y cualquier stakeholder del proyecto debe participar en la definición de las historias de usuario. La conversación posterior nos permitirá llegar a un acuerdo. Cuanto mayor es el número de involucrados en el acuerdo más fácil es trabajar en la dirección correcta y aportar el valor deseado y esperado al software.

Menos es más. Las historias de usuario nos permiten definir las funcionalidades de una forma concreta, pequeña, fácil de mantener y sin grandes documentaciones. Si la comunicación es un problema, la documentación excesiva también lo es. Las historias de usuario deben contener sólo la información imprescindible.

Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!

También te puede interesar...
Pitu Sabadí
Pitu Sabadí
TDD and Agile enthusiast

CEO en Please Networks. Profesor de Agile en el Máster de UIUX en ESDi. Fullstack developer y believer en la vida real. El trabajo en equipo, la mejora continua y las dinámicas de grupo constituyen las motivaciones de este blog.