Cómo escribir buenas historias de usuario

Tiempo aproximado: 5 min.

En vista del impacto que ha tenido un hilo-rant que publiqué hace unos días en Twitter con ejemplos desoladores de historias de usuario reales, he decidido escribir algunos consejos sobre cómo escribir buenas historias de usuario.

El hilo era éste y decía lo siguiente. (Lo voy a reproducir aquí porque creo que así se lee mejor y además aquellos que no tengan Twitter también lo podrán leer).

«Como P.O. quiero…» NO ES UNA HISTORIA DE USUARIO. El P.O. no es un usuario.

«Como <equipo tal> quiero…» NO ES UNA HISTORIA DE USUARIO. El equipo no es un usuario.

«Como <usuario (así, en general)> quiero recortar el combo tal para mejorar la experiencia de usuario» NO ES UNA HISTORIA DE USUARIO porque no explica la necesidad concreta del usuario que mejoraría su experiencia. (Sin hablar de que usuarios en general hay muchos)

«Como usuario de la aplicación quiero migrar la funcionalidad XYZ para adaptarla al nuevo modelo» NO ES UNA HISTORIA DE USUARIO porque si le preguntamos a los usuarios seguro que les importa una mierda tu migración. Una migración NO APORTA VALOR a los usuarios sino a la empresa.

El hilo concluye con una diatriba dirigida a los responsables de enseñar cómo se utilizan las historias de usuario para desarrollar software, pero vamos a dejarlo para el final del artículo.

¿Qué es una historia de usuario y para qué sirve?

Hace bastante tiempo que recogí una definición de Historia de Usuario en la sección Guías de Agilismo de mi web. La verdad es que no ha envejecido del todo mal.

Una historia de usuario sirve para que cada pieza de software que construimos esté enfocada en aportar valor a los usuarios que terminan usándola. No hay mucho más. Sin embargo, las historias de usuario son el resultado de muchísimas conversaciones y decisiones que se van tomando (no sólo en el ámbito del equipo), por lo que es importante entender y haber participado en las mismas siempre que se pueda.

Algunos consejos

  • Una historia de usuario es un trabajo de equipo: no dejes que sea trabajo en solitario del Product Owner (si alguien ejerce ese rol).
  • Empieza por identificar al usuario que usará el resultado de la historia. La user persona es una buena técnica para entender mejor a quien usa tu software. Los compañeros de UX o de Marketing suelen trabajar con estos artefactos, aprovecha e invítalos a trabajar juntos en las historias de usuario.
  • Sigue identificando claramente cuál es la necesidad que tratas de resolver. Imagina que vas a poner un botón nuevo en tu aplicación. ¿Qué necesita hacer el usuario cuando encuentra tu botón? ¿Pulsarlo? Nooo. Nadie necesita pulsar un botón. Quizás necesita comprar, meter en un cesta de la compra, conocer el precio de un artículo,… pero nunca pulsar un botón. El botón es el equivalente a un informe trimestral de ventas. Nadie necesita un informe, en realidad lo que le hace falta es responder a la pregunta de si han subido o bajado las ventas en el último trimestre. Por ejemplo. Piensa en ello.
  • El feedback de los usuarios es importante para escribir historias que les aporten valor. Si tenéis un departamento de atención al cliente, pregúntales. Te sorprenderán por lo bien que conocen las necesidades de los usuarios y los puntos de dolor de tu aplicación.
  • No olvides acordar el criterio de aceptación con todo el equipo. Me parece buena práctica escribir, al menos, cómo utilizaría el usuario la funcionalidad en cuestión. De esa manera no se nos olvidarán detalles como los mensajes de feedback al usuario. Si hay especialistas en testing (QA) en tu equipo/departamento, pídeles que se involucren en la creación de las historias de usuario. Ellos saben responder a la pregunta «Y esto, ¿cómo lo probaremos?». Eso sí, ojo, no confundas el Criterio de Aceptación con el Plan de Pruebas.
  • Me gusta el formato «como…quiero…para…» porque nos ayuda a tener foco y no olvidar a qué usuario estamos aportando valor. También nos permite entender bien cuál es la necesidad del usuario que queremos cubrir y, por tanto, nos da la oportunidad de elegir la solución que más nos convenga. Sin embargo, una historia de usuario no necesita ser escrita, ni siquiera dibujada, lo único imprescindible es la conversación. Por favor, recuerda esto siempre.
  • JIRA. (Casi) todo el mundo conoce el issue tracker de Atlassian y muchos se quejan de la herramienta cuando en realidad lo que pasa es que la están usando para lo que no es. Tener las historias en JIRA puede estar bien si, por ejemplo, necesitas medir tu flujo de trabajo para mejorarlo. También puede ser apropiado si quieres tener un tablero digital en el que sea fácil de compartir la información de todo el equipo, o incluso agregar la información de varios equipos. Pero trata de guardar en JIRA la menor información posible porque JIRA no es un gestor documental. Si necesitas añadir criterios de aceptación muy detallados, piensa antes si no son señal de que tu historia es demasiado grande, y luego mira si puedes llevar todo ese detalle a otro sitio. He trabajado con muchos equipos que mantenían todos esos detalles en otras herramientas como Confluence (la wiki de Atlassian) o Google Drive.
  • Piensa en historias «pequeñas», es decir, en pequeños cambios en tu aplicación. Y luego en otras que construyan sobre las anteriores. Es lo que llamamos desarrollo incremental de producto.
  • A veces es necesario hacer un trabajo previo para tener una idea de qué estamos construyendo (un plan). Una Agile Inception, un User Story Map o un Impact Map son buenas técnicas a valorar, sobre todo porque ayudan a poner a todos de acuerdo. Me han hablado muy bien de Event Storming pero aún sigo sin haber podido dedicar tiempo para estudiarlo.
  • Si se trata de arreglar un defecto, especialmente si la aplicación fue desarrollada hace tiempo, te encuentras ante una historia de usuario que nunca se escribió. Aunque te resulte extraño, trata de escribir esa historia de usuario y de ver por qué no se cumple el criterio de aceptación. Igual encuentras más de un defecto a arreglar.

Historias de usuario mainstream

Aunque ahora Agile es mainstream, parece que sólo lo es nominalmente. Me explico. Es fácil encontrar organizaciones que dicen estar aplicando métodos ágiles para el desarrollo de su software pero que apenas han incorporado algunos cambios en sus procesos y en la manera de organizar el trabajo: ceremonias, algunos roles y poco más.

Hace años nos reuníamos para aprender unos de otros, entre otras cosas, qué eran las historias de usuario y cómo usarlas en nuestras respectivas situaciones. Una de las dificultades más recurrentes, también en mis formaciones, era cómo escribir las historias para que representaran necesidades de los clientes. Creo que no se está trabajando la importancia clave de ayudar a superar esta dificultad.

Mi blog está plagado de referencias a las historias de usuario, hasta el punto de haber dedicado una serie completa a las mismas: «El desarrollo de software son conversaciones». Incluso y yo creamos hace unos 4 años un site llamado historiasdeusuario.com. Lo dejamos aparcado porque no teníamos energía suficiente en aquel momento, pero en él dejamos algunas UserStoryKatas, ejercicios para reflexionar sobre cómo escribir buenas historias de usuario. Siéntete libre de usar todo ese material. Está ahí para ser compartido.

Conclusión (rant)

El hilo-bronca terminaba así:

No termino de entender bien cuál es la razón por la que proliferan estas historias de usuario tan deficientes en los backlogs de equipos que, al menos formalmente, han recibido formación y están acompañados por profesionales certificados y con plena dedicación a estas tareas de formación y acompañamiento. Seguramente, como en la mayoría de los sistemas complejos, las causas son múltiples. Así que quizás sea el momento de renovar el site de historiasdeusuario.com y darle utilidad de nuevo. ¿Qué te parece? Déjame un comentario aquí, en Twitter o en LinkedIn para saber qué apoyo tiene la iniciativa.