Reflexionando sobre Historias de Usuario en entornos no puramente de desarrollo (como BI)

Habrá muchas más, pero si hay una buena práctica típica Ágil que cuesta mucho que se lleve a cabo medianamente bien es la de… las famosas Historias de Usuario. Cuestión que podría generalizarse a qué va en un Product Backlog (tema que ya tratamos en la serie de post cualquier cosa que pida un cliente, y pague por ello… ¿Va al Product Backlog? ¿Qué va a un Product Backlog? (1/2))
En estos últimos tiempos no tanto, pero de hace tiempo hay muchos post en el blog hablando sobre Historias de Usuario. Aunque, siendo rigurosos (si que haya un necesario rigor prescripitvo), un Product Backlog contiene Items, que es muy genérico, lo típico es que el concepto de Historia de Usuario (como un tipo de Item) ayude a centrar si lo que hay en un Product Backlog tiene buena pinta.
Los principales problemas que me suelo encontrar aquí son los siguientes:
– Historias que no son Historias, son Tareas (un cómo en vez de un qué), por lo que no son un «end to end» que terminado aporte valor por sí mismo a un usuario.
– Historias que son excesivamente grandes (¿Por qué las Historias de Usuario deben ser lo más pequeñas posible? y estrategias para descomponer y hacer pequeñas historias de usuario)
Superados los anteriores, podríamos entrar en el Valor que aportan, sin se pueden probar, si el formato clásico para escribir Historias es el más apropiado (Shu-Ha-Ri), si aplica más la idea de By Example, los DoD, los DoR, etc. Pero la realidad es que, la mayoría de las veces, no llegamos a estos puntos porque no pasamos de los dos que te contaba antes.
El problema se acentúa aún más cuando entras en entornos que están aplicando Agilidad y no son puramente de desarrollo software. Ahí se hace más fuerte el síndrome del “Es que nuestro caso es especial, somos diferentes”, no podemos hacer Historias (o llamamos Historia a cualquier cosa que, sin serla, se meta en un Product Backlog).
Uno de esos entornos, entre otros tantos, que tiene su especial «lucha» con las Historias de Usuario es el de BI (Business Intelligence), donde el principal argumento es que «lo que hacemos lleva mucho tiempo, semanas, como para poder aplicar la idea de Historia de Usuario», que suene ser algo pensado para terminarse en días (en los post previos que te cité trato más este punto del tamaño de las Historias).
Si es tu caso, para darte esperanzas en la lucha, a día de hoy, aún no me he encontrado una situación en BI en la que, funcionalmente, analizando el caso, explicando bien el concepto, no se pudiese trabajar con Historias de Usuario de las de verdad. Si ha sido imposible que sean pequeñas no ha sido por problemas de carácter funcional, ha sido por problemas de tecnología «legacy», externalizaciones y silos, y cosas del estilo.
Hay mucho material por ahí de cómo descomponer grandes Historias (que probablemente por eso no sean Historias), y no era objeto de ese post tratar el detalle de las descomposición (hay un post antiguo, de carácter general, que trató esto, el de estrategias para descomponer y hacer pequeñas historias de usuario). Pero que sepas que… raramente es imposible por naturaleza funcional no poder descomponer funcionalidad en Historias (también en BI).

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

3 comentarios en “Reflexionando sobre Historias de Usuario en entornos no puramente de desarrollo (como BI)”

  1. Hola, Javier
    Podrías proponer algunos ejemplos de historias de usuario reales para un sprint de un equipo de BI? Podría ser bastante útil.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *