He notado que muchas personas siguen sin comprender la esencia de las Historias de Usuario y continúan cayendo en el anti-patrón de escribirlas como requisitos (y sin asignarles un usuario).
Cuando definamos una historia de usuario, debemos ponernos en los zapatos del usuario: la persona que utilizará la nueva funcionalidad.
Es fundamental comprender que las Historias de Usuario deben ser pensadas con el usuario como inicio y objetivo de la funcionalidad.
Al usar el formato «Yo como: nuevo cliente, usuario de la plataforma, conductor del coche…» (recordemos que podemos tener HU es ambientes que no son software) estamos entregando información valiosa a todo el equipo. Tener claro quién es la persona que pide una funcionalidad nos ayuda a comprender la necesidad, y por ende, la solución a su necesidad.
Tomemos el siguiente ejemplo de una misma HU escrita desde dos usuarios diferentes:
«Yo como
Dueño del Producto / Negocio
quiero obtener la información de costos mensuales para poder tener bases para la toma de decisiones»
«Yo como
Gerente de ventas
quiero obtener la información de costos mensuales para poder tener bases para la toma de decisiones»
¿Cuál de las dos Historias de Usuario nos proporciona más información? Cuando la petición viene en boca del Dueño de Producto, o del Negocio, no es tan clara la intención y la necesidad. Cuando la petición viene en boca de un Gerente de ventas, transmitimos un información y contexto sobre la persona que tiene la necesidad descrita en la HU.
Al conocer que la información solicitada es para que un gerente de ventas pueda tomar decisiones, podemos visualizar un informe gerencial, con gráficos claros y con la información tabulada y pensada para dar soporte a las ventas de la compañía. Pero al recibir la petición desde el «negocio», ¿qué tipo de formato construirías? ¿cuánto tiempo requerirías para averiguar la finalidad real de la información? ¿cuántos sprints requerirías para corregir el formato hasta encontrar el que realmente resuelva la necesidad?
Conocer el usuario para quien estamos resolviendo la necesidad nos proporciona una idea sobre su contexto y nos brinda la posibilidad de encontrar acciones de mejora, mientras que un extenso requisito, lleno de especificaciones técnicas, nos permitirá construir algo (tal vez sin comprenderlo), pero no nos permitirá aportar más allá de lo especificado.
Referencias
- Para ampliar un poco más, te invito a leer: Dos Errores Comunes en las Historias de Usuario, por Jorge Abad.
- Imagen de Stux, tomada de Pixabay.