¿Quién escribe las historias de usuario? ¿El Product Owner? ¿El Product Manager? ¿El propio equipo?
Es una pregunta que sale de forma recurrente en los equipos. En la mayoría, es algo que hace el Product Owner. Es la única perspectiva que los desarrolladores tienen sobre “lo que pide” el cliente. Un documento de requisitos escrito por un proxy de un proxy del cliente, con el que jugamos al teléfono roto.
Nos pasamos más tiempo pensando cómo escribir este documento, que pensando qué es lo que necesita el cliente realmente.
La idea es otra.
Lo primero, es entender que las historias de usuario NO son los requisitos.
Son la herramienta que, como equipo de desarrollo, usamos para entender esos requisitos.
Las usamos, porque es el formato que captura de forma más fidedigna la conversación con el cliente, en la cual nos cuenta, oh sorpresa, una historia 🤓
Pero lo importante de la historia no es el soporte escrito: es la conversación.
La conversación es donde van a estar todos los detalles. Es a partir de lo que vamos a construir de verdad conocimiento compartido. Porque ya lo dice el dicho, “hablando se entiende la gente”.
El soporte escrito, la tarjetita, el ticket de JIRA, el “As a user I want to…”, es un mero trigger de esa conversación. Un artefacto que representa esa conversación para poder jugar con su prioridad cuando planifiquemos, o nos ayude a recordar lo que hablamos cuando lo necesitemos.
Pero NO es un sustituto de esa conversación.
Por tanto, ¿quién debe escribir las historias de usuario?
La respuesta es que da igual. Lo que importa es que todos los que estamos involucrados en construir el producto (equipo de desarrollo, cliente, stakeholders) participemos en la conversación.
