Hace algún tiempo quedé con una amiga para almorzar. Esta chica había trabajado muchos años como Scrum Master e incluso como Agile Coach durante una temporada. Actualmente, estaba trabajando en un cliente final como gerente, y por su curriculum, tiene una visión muy amplia del mundo software. Estábamos hablando de la medición de valor y me dijo: “Javi, el gran problema de medir valor es que nadie sabe qué valor te va a aportar cada Historia de Usuario”. Recordemos que las Historias de Usuario son un tipo de elemento de Product Backlog pero no están recogidas en Scrum, aún así, son bastante utilizadas porque describen el comportamiento de un usuario frente a nuestro software. Veamos algunas ventajas si medimos el valor de nuestras historias.
Mejor priorización
Si podemos asignar un valor a cada HU, entonces podemos saber cuánto nos van a aportar y por tanto, podemos hacer un priorización en valor en nuestro Backlog. Si además, como vimos en la formación de PSPO, utilizamos más variables como el tamaño (medido en horas, puntos de historia o cómo sea) y el riesgo (dependencias o elementos que me impidan entregar), podemos hacer una buena maximización de valor.
Mejor control del producto
Si el Product Owner dispone de un valor por HU, entonces podemos utilizar perfectamente el BurnUp Chart, que mide el valor acumulado por Sprint. De esta manera, podemos hacer proyecciones futuras de valor entregado y defender en un comité el valor futuro que vamos a aportar. Además, si el valor previsto para el siguiente Sprint es bajo podemos decidir incluso cancelar y no desarrollar más el producto.
Mejorar la analítica
Si tenemos un valor asignado por HU, entonces podemos hacer mediciones con Google analytics u otra herramienta y relacionarlas con nuestra Historia. Así, sabremos si estamos cumpliendo lo que queríamos o tenemos que darle una vuelta a nuestra funcionalidad.
Todo parece muy bonito pero…
¡No se puede! Siento dar esta mala noticia, no tenemos forma de saber cuánto valor me aporta directamente cada HU. Medimos el producto y las HU que acometemos son el conjunto de mejoras que queremos añadir a nuestro producto para que esas métricas de producto mejoren. La clave, por tanto, está en el producto en sí, pero no en cada HU por separado.
Cuando usamos una técnica de asignación de valor relativo, por ejemplo “esta HU son 5000 y esta otra 2500”, simplemente estamos diciendo que creemos que con la primera obtendré el doble de valor que con la segunda, pero no lo sabemos realmente. Además, generalmente hacemos subidas a producción de varias HU con lo que no sabemos si una de ellas es dañina y está camuflada por otras buenas. Y aunque hiciéramos una subida funcional: en cuanto acabáramos una HU, subirla directamente, tampoco podríamos saber el valor que nos proporciona directamente.
Al igual que los puntos de historia, el valor relativo asignado no tiene importancia. Tanto los puntos de historia como este valor solo sirven para tener discusiones y debates sobre lo que es importante y con ello decidir qué acometemos a continuación. Pero, no podemos buscar en ellos la certeza de lo que nos llevará hacer algo o del valor que aportará, son hipótesis.
¿Qué es medir valor?
Medir el valor es medir el producto y no medir el conjunto de historias por separado y sumarlo. Cuando usamos Evidence Based Management, lo que queremos es medir el producto en sí. Medimos el time-2-market o el índice de uso de las funcionalidades pero no el dinero que me da cada una de ellas.
Un par de ejemplos
No puedo saber cuánto valor me da una funcionalidad, pero si puedo medir otras cosas que me digan si está alineado a lo que quiero. Si nos contratan para mejorar un periódico online, es difícil saber si la HU que tenemos delante nos dará más o menos dinero. Sin embargo, una característica bastante habitual es la de tratar de retener al usuario mucho tiempo en el periódico. Como decían el otro día en la radio, “vivimos en el imperio del click”. Podemos medir por tanto el tiempo que pasa nuestro usuario en cada una de las pantallas y, con ello, saber si mis historias están fomentando eso o no.
Un caso contrario puede ser cuando nos contratan para hacer una aplicación interna que mejore la productividad de unos administradores. El objetivo es que en poco tiempo hagan una operación concreta, y cuanto más bajo sea el tiempo empleado, mejor. Al medir ese tiempo, estamos descubriendo si nuestro producto ayuda o no ayuda. ¡Eso es valor!
¿Cómo mido valor en mi producto?
El mejor consejo es tener talleres con los stakeholder claves que nos definan la visión y el fin de nuestro producto y, con eso, trabajar. Una técnica que recomendamos mucho es el Impact Mapping en el que se definen objetivos e impactos, y asignamos KPIs a esos impactos. Si tenemos claro qué es valor para nosotros, podemos saber en cada Sprint si nos estamos acercando o alejando de nuestros objetivos. De esta manera podemos tratar de llevar el debate de entrega-fecha a un debate más rico sobre lo que nuestro software aporta a nuestra organización.
A la hora de definir KPIs, es bueno no obsesionarnos con todos al principio. Elegir unos KPIs claves que nos digan si tenemos éxitos y otros que nos digan si vamos en el buen camino. Por ejemplo, si estamos desarrollando una web de seguros, el KPI principal puede ser la tasa de conversión (usuarios que entran por los que contratan). Mientras que, otros KPIs pueden ser el tiempo que los usuario pasan hasta contratar o cúanto tiempo invierten en la página de elegir seguro concreto.
Por último, es importante a la hora de medir el valor de nuestro producto las métricas más relacionadas con el propio equipo. Un ejemplo es medir su grado de satisfacción, recordemos que son el músculo que desarrolla nuestro producto y es clave que estén motivados. Otros medidores como el cycle time que nos dice el tiempo en el que desarrolla una historia nos puede ayudar a conocer a nuestro equipo.
Estos son sólo algunos ejemplos, os animamos a plantearos un modelo basado en valor, donde se defina qué es, se mida, y se tomen decisiones en base a lo descubierto.
¿Cómo medís valor en vuestros productos?
