¿Qué son las Historias de Valor?
Alonso Alvarez
- Agilidad Empresarial
- Artículo
Que el valor y la gestión del valor es un aspecto crítico en cualquier organización es algo evidente.
También es evidente que “valorar el valor”, es decir medirlo de una forma objetiva y consistente, es una dificultad. Aunque usemos entidades como el CoD (Cost of Delay) es verdaderamente complicado medir el valor.
Aunque lo traduzcamos a ingresos en dinero contante y sonante, sabemos que hay muchas acciones valiosas que no se convierten con facilidad en un valor monetario (por ejemplo, mejorar la percepción externa de nuestra organización para atraer talento, o aumentar la confianza de nuestros clientes).
Para facilitar las cosas, el valor se desvanece con facilidad. Un cambio de estrategia, de directrices, de contexto y el valor se esfuma. En un producto o servicio en construcción, la frontera entre valor esperado y desperdicio (cuando deja de ser necesario, cuando no llega a tiempo, …) se cruza con facilidad.
El concepto de “historias de valor” (o VS de Value Stories) no es una solución mágica, pero sí una ayuda a la hora de gestionar el valor y el trabajo que requiere alcanzarlo, por ejemplo, en la gestión del portfolio o en el VSM (Value Stream Management).
Este concepto se describe con más detalle en varios sitios. Aquí tomamos como referencia el libro “The Journey to Enterprise Agility” de D. Kulak y H. Li que es, por cierto, una lectura recomendada que aporta a la Agilidad una visión técnica desde el lado de Sistemas.
Definir Historias de Valor
A estas alturas no hace falta explicar qué es una historia de usuario. Una historia de valor tiene una estructura similar, pero su objetivo es sobre todo conectar el ROI (Return of Investment, Retorno de Inversión) con el trabajo desarrollado por un equipo durante la construcción de un producto o servicio.
Una historia de valor se puede ver como un grupo de historias de usuario, pero no es una épica. Las VS siguen este formato:
Como < empresa> quiero <crear algo> para poder <lograr algo>
Un par de posibles ejemplos serían:
- “Como BuenERP SA quiero incluir una funcionalidad de gestión de activos para poder incrementar las ventas de mi producto en 5 a 10 M€”
- “Como FábricaMediana SL quiero rehacer mi sistema de pedidos para poder eliminar el antiguo y ahorrar al menos 600 K€”
Aunque parezca que son una forma abreviada de Business Case o afirmaciones sobre el ROI, se puede ver como no hay ninguna mención a la inversión necesaria.
Algunos aspectos que hay que tener en cuenta sobre las historias de valor:
- Las historias de valor se crean al comienzo de un ciclo de trabajo (versión, entrega, release) para organizar el backlog.
- Puede haber varias de estas historias de valor en cada versión o release de producto, no son un objetivo único o exclusivo.
- Una historia de valor no tiene por qué ceñirse únicamente a la obtención de beneficios económicos. También pueden incluir otros objetivos como la satisfacción del cliente, imagen de la empresa, o reducción de tiempos. Si describen un beneficio económico pueden incluir ingresos o ahorros, y en esos casos se pueden usar rangos para evitar una falsa sensación de precisión.
- Las historias de valor no son estáticas. Pueden cambiar a medida que equipo y stakeholders aprenden más sobre el problema y la solución que están construyendo.
- Las historias de valor no son épicas: una historia de usuario puede formar parte de una o varias historias de valor. A veces, concluir el trabajo necesario para unas historias de valor determinadas, hace que también se complete el trabajo para otras.
¿Para qué nos sirven las historias de valor? Son, por ejemplo, una ayuda para priorizar historias de usuario, especialmente cuando nuestro producto es grande y tenemos un gran número de ellas.
Al contrario que las épicas, que nos describen las principales funcionalidades de un producto o servicio, las historias de valor nos informan de lo que busca obtener la organización. Las historias de valor ofrecen información sobre el end-to-end y son una manera de aportar información sobre el propósito, muy importante para generar alineamiento.
Gestionar las Historias de Valor
Las VS se pueden priorizar, al tiempo que ayudan a la priorización. Para esa priorización tenemos una información decisiva, que es el ROI asociado, pero no tiene por qué ser el único criterio.
Al contrario, lo recomendable es, al menos combinarlo con el esfuerzo, la criticidad en el tiempo y algún otro criterio para evitar que, por ejemplo, actividades muy necesarias, pero de naturaleza técnica o interna, no se prioricen por no tener una VS asociada.
En estos casos suele ser recomendable hacer reservas de esfuerzo para, por ejemplo, solucionar deuda técnica o realizar actividades que mejoren las condiciones de trabajo (formaciones, herramientas, nuevas capacidades, experimentos).
A veces las historias de valor son muy grandes, lo que dificulta trabajar con ellas. Incluso es posible que no se puedan llevar a cabo en un periodo determinado (el de la próxima release o entrega). Por ese motivo merece la pena dividirlas.
La división de historias de valor puede hacer que no se obtenga todo el valor previsto hasta que no se completen todas sus partes, pero al menos permite recibir parte del valor previsto. En la división de VSs se pueden aplicar técnicas ya conocidas en la división de USs como:
- Funcionalidades.
- Segmento de clientes.
- Requisitos no funcionales.
- Niveles de calidad.
- Conexión con otros componentes y sistemas.
- Casos de uso.
El valor de las Historias de Valor
Usar historias de valor ayuda a proporcionar intención y visión en un proceso de construcción o desarrollo de productos y servicios. El cálculo del ROI y el Business Case suele quedar en el cajón (y la cabeza) de un equipo de finanzas, completamente alejado del conocimiento de las personas que hacen que las peticiones de Negocio se traduzcan en algo tangible. En su lugar, las VS proporcionar información muy valiosa y disponible para cualquier persona en cualquier nivel.
Son además un punto de contacto y un lenguaje común entre personas de negocio y técnicas, ayudando a cerrar una de las divisiones que más daño hace dentro de las organizaciones. Son una forma de poner foco en resultados o outcomes y no sólo en las salidas o outputs.
Sin embargo, también hay que ser conscientes de que, a la hora de medir su efectividad, el ROI tiende a moverse en marcos temporales mucho más amplios de los que determina una entrega, release, versión o evolución de producto.
Por ello, es conveniente combinarlo con otro tipo de métricas orientadas a outcomes o estructurarlo temporalmente para evitar generar frustraciones innecesarias si no se alcanza el objetivo de manera inmediata.
