Las Historias de Usuario son piezas de contenido escrito donde, haciendo uso de la descripción por escenarios, desarrollo orientado a comportamiento (BDD), definimos una funcionalidad, necesidad o solución poniendo al usuario en el centro, contando su historia.
La Historia de Usuario busca la colaboración continua entre todo el ecosistema social de producto involucrado, impactado o interesado en este desarrollo para crear productos de alta calidad y adaptados a las necesidades de los usuarios mediante descripciones claras y concisas.
El origen de las Historias de Usuario (HU, US o User Stories) se remonta a 1990 bajo el marco de trabajo agile eXtreme Programming. No, no tienen su origen en Scrum. Provienen de XP y Scrum las populariza.
Antes de entrar en formatos, es importante…
Las 3 C’s de Jon Jeffries
La Historia de Usuario es una parte fundamental de la cadena de colaboración que va desde la definición de la necesidad hasta la puesta en producción del desarrollo resultante y su posterior seguimiento mediante métricas. Sin embargo, la Historia de Usuario sería la tarjeta, la pieza escrita, una de las 3 C’s de Jon Jeffries, faltan otras dos sin las cuales la cadena de colaboración no aporta verdadero valor al usuario:
- Card (Tarjeta): Una HU se escribe tradicionalmente en tarjetas, post-its, etc. y debería ser lo suficientemente simple para encajar en este formato y permitir la colaboración.
- Conversación: Una HU expresa de forma clara y sencilla el propósito esperado de la funcionalidad y debe fomentar la conversación para determinar la mejor solución.
- Confirmación: Una HU contiene los elementos (CA’s, DoD, etc.) que permitirán confirmar su finalización con éxito y ofrecer así la solución esperada por el cliente.
Son tres piezas sin las cuales la HUs no tiene sentido. No debe existir el contenido escrito sin una conversación, a poder ser, en refinamientos o reuniones específicas para recoger la necesidad o trasladar la funcionalidad. Si la primera vez que tenemos esta conversación con el equipo de producto es en la planificación… ¡Alarma! Algo está fallando, probablemente la comunicación, y falta alguna que otra sesión de refinamiento. Por otro lado, además de la escribir la HU y mantener la conversación necesitamos definir una serie de elementos que nos permitan verificar el éxito o no-éxito de la HU.
Épicas e Historias de Usuario
Entonces, ¿qué diferencia hay con las famosas Épicas? ¿Y con las Iniciativas? ¿Y con las Features? En este punto se aplica la regla del monopoly: En mi casa al monopoly se juega así. Es decir, en cada empresa se trabaja un tipo de jerarquía o sistema de organización de Historias de Usuario diferente. A mí, personalmente, la jerarquía que más me gusta es la siguiente (usando a Juego de Tronos como ejemplo):
- Problema: necesidad u oportunidad recogida desde negocio, stakeholders o directamente desde los usuarios. Ej: problema al que se enfrenta el mundo de Juego de Tronos al acabar la temporada anterior (Z-1).
- Solución: cada una de las potencialidades soluciones que podemos abordar para trabajar el problema anterior. Ej: trama global de la temporada Z de Juego de tronos que pretende solucionar el problema generado en la temporada anterior.
- Iniciativa: conjunto de épicas a trabajar por cada uno de los equipos involucrados en el desarrollo de la solución anterior. Ej. La temporada Z de Juego de Tronos con todas las tramas y subtramas, donde cada capítulo es independiente pero la suma de todos aporta el valor necesario para la solución prevista.
- Épica: conjunto de Historias de Usuario a desarrollar por un equipo de producto para empujar a la iniciativa anterior. Ej: El capítulo X de la temporada Y, ya que el capítulo aporta valor de forma independiente pero al agregarlo a la temporada suma un valor adicional a la historia.
- Historia de Usuario: la pieza mínima e independiente que podemos poner en producción para validar la necesidad y el aporte de valor al usuario. Ej: La historia de Tyrion dentro del capítulo X, ya que es independiente pero al sumarla con las otras HUs aporta un valor agregado.
- Tarea Técnica: cada una de las acciones o actividades técnicas necesarias para completar la Historia de Usuario anterior. Ej: cada una de las escenas de la historia de Tyrion, que por sí sola no aporta ningún valor pero al sumarlas todas forma la historia independiente que aporta valor por sí misma.
Formato de una historia de usuario
La forma correcta de escribir historias de usuario es un tema que genera debate. También es cierto que nos encanta el debate sano cuya conclusión acaba con un aprendizaje. Vamos a ver algunos tips para arrancar de manera adecuada.
Antes de empezar, recuerda que el formato o estructura de una HU es un acuerdo al que debes llegar con tu equipo de producto. Lo que encontrarás aquí son recomendaciones pero 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. 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 la estructura «Como...», «Quiero/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 asegurar que escribes las HUs con tus usuarios en mente. Evita siempre empezar así: “Como Negocio…”, “Como Product Owner…”, “Como Stakeholder/Marketing/Ventas/Seguridad/Legal…”. Busca siempre empezar con “Como Usuario…” y así lo tendrás siempre en el centro
- Una descripción detallada de los escenarios usando BDD, mockups, maquetas, flujos de navegación, diagramas de decisión, o una combinación de todo lo anterior (recuerda validar qué es lo que necesita tu equipo para arrancar y márcalo como Definition of Ready).
- Todos y cada uno de los recursos y contenidos, en caso de ser necesarios, para no empezar con dependencias.
- Las métricas de éxito así como el etiquetado que permitirá el seguimiento posterior usando la herramienta que tengas a tu disposición.
- 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).
- Una lista con el Definition of Done para asegurar que la HU está lista para pasar a Review, para ser validada y/o para pasar a producción y empezar a medir.
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 o Product Manager 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 el modelo INVEST.
Independiente: Una historia de usuario debe ser autosuficiente, es decir, que no debe depender de otras historias para no provocar problemas al probarla.
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 factibles en un periodo de tiempo relativamente corto y que no implique demasiada complejidad. 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. Si te queda una HU grande (en mi opinión sería todo aquello mayor de 3-5 puntos de esfuerzo) te recomendamos seguir la guía de The Humanazing Work para cortar la HU y hacerla más pequeña.
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. Si has seguido la definición de escenarios usando BDD, y has usado Gherkin para tus Criterios de Aceptación podrás generar una batería de pruebas de forma sencilla.
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 las personas que lideran producto a mejorar sus historias de usuario intentando seguir un conjunto de reglas.
Ten siempre en cuenta que no debes 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 dentro del ecosistema social de producto.
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: 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, como este, guiño guiño.
Pide feedback a menudo al equipo de producto para conocer cómo podríais mejorarlas. Te animamos a hablar de esto con tu equipo en las retrospectivas.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
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.
Foto de Tim van der Kuip en Unsplash
