Este es el quinto mandamiento del libro «Agile Product Management». Descárgalo y obtén las claves para crear productos digitales de éxito.

Formato de una historia de usuario

La forma correcta de escribir historias de usuario es un tema muy debatido. A lo largo de este mandamiento intentaremos darte algunos consejos e indicaciones para que arranques de la manera que creemos que es la más adecuada.

Sin embargo, no te olvides de que todo lo que encontrarás aquí es una recomendación y que la forma correcta de escribir historias de usuario siempre será la que mejor os funcione a ti y a tu equipo.

Igual que con muchos otros conceptos ágiles, el equipo de desarrollo tiene la última palabra respecto a cómo de clara y preparada está una historia de rio. Como Product Owner, tienes que trabajar para asegurarte de que tus historias encajan con tu equipo y no al revés. Da igual lo que hayas leído sobre formatos y buenas prácticas para escribir historias de usuario; tienes que escuchar a tu equipo.

Dicho esto, aquí tenemos un formato de historia de usuario muy extendido para que puedas empezar, inspirarte e iterar sobre él.

Una historia de usuario debería incluir:

  • Un título: «Pago de cliente con tarjeta VISA».
  • Una descripción narrativa utilizando las estructuras «Como…», «Necesito…», «Para…». Por ejemplo: «Como cliente con tarjeta VISA, necesito introducir los datos de mi tarjeta para pagar los elementos de mi carrito de la compra» Utilizar este enfoque tiene la ventaja de asegurarte que estás escribiendo las historias de usuario con tus usuarios en mente, comenzando por lo que están intentando hacer y por qué.
  • Una lista de criterios de aceptación. Estos te ayudarán a mencionar todos los detalles que no se mencionan en la descripción de más arriba y a expresar todas las cosas que esperas que se desarrollen alrededor del núcleo de lo que estás describiendo en tu historia de usuario. Por ejemplo, un criterio de aceptación para este caso sería que el formato de la tarjeta VISA tiene que verificarse cuando el cliente la escribe (hablaremos de esto después).

En algunos equipos debería ser suficiente una historia de usuario muy esquemática para que empiecen a desarrollar la feature correcta. En otros, las historias de usuario deberán parecerse más a una mini especificación. Por supuesto, el nivel de detalle que decidas incluir en cada historia puede variar según su complejidad.

Nosotros hemos observado que cuanto más próximo está el Product Owner a su equipo, más cortas y concisas son las historias de usuario. Sin embargo, por muy buena relación que puedas tener con tu equipo de desarrollo, cada historia de usuario debería superar cada paso del modelo INVEST.

Independiente: Una historia de usuario debe ser autosuficiente, es decir, que no debe depender de otras historias para no provocar problemas de prueba planificación.

Negociable: Una historia debería estar siempre abierta a discusión e iteración. Tus equipos de desarrollo y pruebas tienen que poder opinar. Valiosa: Todas las historias deben aportar un valor tangible a tus usuarios, por eso estas se expresan con una descripción narrativa que gira alrededor de ellos.

Estimable: Una historia de usuario tiene que ser lo suficientemente clara y precisa para que el equipo de desarrollo pueda estimarla.

Pequeña (Small): Intenta siempre escribir historias de usuario que describan una tarea de desarrollo factible en un periodo de tiempo relativamente corto y que no implique demasiada complejidad en una sola tanda. Esto evitará una visión de túnel o limitada y te asegurará ser capaz de entregar una nueva versión de tu producto con frecuencia.

Probable (Testable): Una historia de usuario describe una narrativa orientada a ciertos objetivos, lo que significa que deberías ser capaz de probar todas las historias una vez que se hayan completado.

Por supuesto, el modelo INVEST es un conjunto de directrices que no siempre vas a poder seguir. Por ejemplo, de vez en cuando habrá interdependencia entre las historias de usuario, por lo que tendrás que priorizarlas con cuidado. Este modelo es una herramienta para ayudar a los Product Owners a mejorar sus historias de usuario intentando seguir un conjunto de directrices.

Ten siempre en cuenta que el Product Owner no debe asumir nunca que una historia de usuario contiene la solución correcta para los problemas de sus usuarios. Cada historia debería escribirse tras recoger toda la información necesaria de los equipos de negocio, los propios usuarios o cualquiera que pueda aportar valor.

Y no dudes en recurrir a maquetas, diagramas, flujos y cualquier otra herramienta visual que te ayude a explicar y aclarar tus historias de usuario.

No olvides que una historia es una narrativa pensada para fomentar el debate y asegurarse de que todos los integrantes de tu equipo están de acuerdo y entienden las necesidades y motivos de los esfuerzos de desarrollo.

Retomando la idea inicial: no te olvides de que el formato correcto de una historia de usuario es aquel que funciona para tu equipo. Evita seguir o adoptar religiosamente y sin adaptar una metodología que hayas leído en un artículo.

Pregúntale a menudo a tu equipo de desarrollo si está contento con las historias en las que están trabajando y cómo podríais mejorarlas. Te animamos a hablar de esto con tu equipo según vuestras retrospectivas habituales.

Criterios de aceptación: el grupo de
trabajo de «los tres amigos»

Los criterios de aceptación son un grupo de criterios que te permitirán validar una historia de usuario una vez que se ha terminado su desarrollo y se han cumplido esos criterios; guiarán a los equipos de desarrollo y pruebas durante su trabajo, así que es importante que todo el mundo pueda opinar sobre ellos y comprenderlos a la perfección. El grupo de trabajo de «los tres amigos» intenta fomentar precisamente eso.

Antes de comenzar con el grupo de trabajo, el Product Owner deberá haber terminado los criterios de aceptación de las historias para compartirlos y discutirlos con el resto de participantes. Los desarrolladores y testers tendrán que haberlos leído antes de llegar al grupo de trabajo, donde aportarán una lista de preguntas y sugerencias.

Tras un debate inicial durante el cual el Product Owner responderá a las diferentes preguntas sobre la tarea de desarrollo descrita en las historias de usuario, deberéis ir elaborando un borrador entre todos con una lista de lo que debe probarse en cada historia.

El grupo de trabajo no consiste en confeccionar un plan de pruebas general, sino identificar las situaciones principales que hay que probar y cómo hacerlo: con pruebas manuales, unitarias…

Lo que debería surgir a raíz de «los tres amigos»

Lo que se creará es una lista de pruebas de aceptación, que les resultarán familiares a aquellos que trabajen en un entorno de desarrollo orientado a comportamiento (BDD). Esto suele formalizarlo el equipo de pruebas o el Product Owner una vez finalizado el grupo de trabajo. Pueden escribirse de la siguiente manera:

DADO (un contexto)

CUANDO (el usuario hace algo)

ENTONCES (se observa el resultado de las acciones dadas)

Una vez que tus criterios de aceptación estén escritos de esta forma, te recomendamos que le pidas a todo el mundo que los vuelva a leer para confirmar que el equipo sigue estando de acuerdo. Esta sintaxis, llamada Gherkin, se utiliza en muchas herramientas que permiten la prueba automática de features, como JBehave y Cucumber.

Cuando utilices este tipo de criterios de aceptación tendrás que escribir criterios concretos con datos reales y no con frases genéricas. Si volvemos a la historia de usuario del pago con tarjeta VISA, los criterios de aceptación quedarían así:

DADO un usuario con un número de tarjeta VISA 4672 6677 8183 8471, válida hasta el 01/2020 y con criptograma 436,

CUANDO el usuario introduce su número de tarjeta 4672 6677 8183 8471
Y la fecha de caducidad 01/2020
Y el criptograma 436

ENTONCES se acepta el pago
Y se redirige al usuario a la página de confirmación de pago

Estos criterios de aceptación están muy bien, pero el grupo de trabajo también tiene la ventaja de garantizar que todo el equipo está en sintonía con el trabajo que hay que hacer en cada historia de usuario. Ahora que todo el equipo comparte la misma visión de la historia, debería ser más sencillo desarrollarla con menos idas y venidas.

Ojo con «los tres amigos»

Como todo lo que proponemos, estos grupos de trabajo solo deben utilizarse cuando tengan sentido. No siempre es necesario tener a tres personas definiendo los criterios de aceptación para una feature básica, y mucho menos para arreglar un error (¡el equipo ya sabe dónde está el fallo!).

Sin embargo, te recomendamos encarecidamente utilizar este grupo de trabajo, especialmente al comenzar un nuevo proyecto o cuando se incorpora un nuevo miembro al equipo, para asegurarte de que todo el mundo comparte la misma idea de cómo debe escribirse una historia de usuario. Con suerte, esto hará que en el futuro haya menos problemas de compresión y podrás dedicar menos tiempo a reescribir historias o a explicárselas a tu equipo.

No te olvides de que tu objetivo es construir un gran producto con la mayor eficiencia posible, y no pasarte el tiempo escribiendo documentación innecesaria.

Descarga-Guia-Agile-Product-Management

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Tu dosis de Cultura de Producto

Una vez al mes. Recibe una editorial y una selección a conciencia de contenidos sobre Product Management y UX Design.
¿Estás dentro?📩