Orígenes de "User story": Extreme Programming "XP" (1998), Agilidad
Una User Story ("historia de usuario" en español) es la descripción funcional utilizada en los métodos ágiles. El objetivo es especificar el desarrollo de una funcionalidad. Debe expresar a quién se dirige y en qué aporta valor.
Generalmente, es redactada por el Product Owner para definir una necesidad ante los equipos de desarrollo, siguiendo una estructura que permite expresar de manera atómica (ver: INVEST), sistemática y clara el interés de la funcionalidad.
Existen diferentes modelos de formulación; por lo general, en un proyecto, los Product Owners acuerdan un "template" claro y compartido. Este incluye las dimensiones "quién", "qué" y "por qué":
Como <quién>, quiero <qué> para <por qué>.
La importancia del <por qué> es expresar claramente el valor de la User Story para el usuario; lo que permitirá priorizarlas en orden de importancia.
El <quién> no se refiere necesariamente al tipo de usuario final del sistema, sino a cualquier rol relacionado con el producto: usuario final de un cierto segmento, tester, desarrollador, administrador, etc.
Las User Stories, en su formato en inglés, a menudo se presentan en dos formas:
As a <define the profile of the user>, I want to <describe the feature> so that <describe the value>
In order to <describe the value>, as a <define the profile of the user>, I want to <describe the feature>
Esta segunda formulación obliga al Product Owner a comenzar definiendo el valor de su historia y evita más fácilmente que la primera caiga en la trampa de repetir el <qué> en el <por qué>.
Ejemplos:
- Como usuario avanzado de MacOS, quiero poder ver el tamaño de todas las carpetas para poder ser más eficiente al limpiar mi disco duro.
- O, como usuario de iPhone, quiero recibir informes de entrega para mis SMS salientes para saber cuándo han recibido mis amigos mis SMS.
- Como gerente de detección de fraudes, quiero evitar que los usuarios creen más de 5 cuentas desde el mismo dispositivo Android para limitar el número de promociones fraudulentas que otorgamos.
La User Story a menudo va más allá de una simple oración y puede formar parte de un grupo más amplio de User Stories que constituyen un conjunto coherente (ver: Épica). La organización global de estas funcionalidades constituye el " Story Mapping," que permite ordenar de manera coherente numerosas User Stories más atómicas y agruparlas en subconjuntos que permiten identificar características coherentes: las Funcionalidades Mínimas Comercializables.
A menudo, una User Story se complementa con una descripción de las reglas de gestión; idóneamente, coescritas entre el Product Owner, el Design y el equipo de desarrollo. Además, el Product Owner puede agregar todos los elementos que permitan al equipo de desarrollo asumir la implementación completa de la funcionalidad, como:
- Los criterios de aceptación o "reglas comerciales".
- La documentación de los wireframes / maquetas y otros elementos gráficos de la interfaz de usuario.
- Los criterios de éxito o "KPIs" a seguir para medir posteriormente el valor de la User Story.
- Las pruebas de aceptación (en formato BDD, por ejemplo: ver BDD y Gherkin) para validar de manera objetiva y sistemática si la User Story se ha implementado correctamente.
Para saber más: Descarga nuestro libro Las Claves del Product Management
