Métricas de Valor para tu equipo Scrum

Hace unos días, hablábamos de métricas, que podemos usar en Scrum, que son fácilmente trucables. Como sabemos, Scrum se centra en generar valor, y debemos definir “valor” en nuestros equipos. Por eso, vamos a hacer un repaso por muchas métricas que podemos incorporar en nuestros equipos para tomar mejores decisiones. Una manera de provocar el cambio de mentalidad en una organización es cambiar lo que se mide.

Recordemos que lo más importante es responder a la pregunta ¿Por qué hacemos este producto? Y, según su respuesta, tenemos que definir qué nos interesa medir para provocar una mejora contínua en el equipo.

Retorno de inversión y costes

Si el valor está relacionado con el dinero, uno de los factores más importante es el retorno de inversión. ¿Cuánto gano con mi nuevo producto? En ciertos productos, el ROI es trivial, por ejemplo en cualquier e-commerce como Amazon. Podemos medir perfectamente los beneficios de nuestro producto.

En los contextos donde no hay una venta directa, tenemos que buscar la métrica que se asocia con el propósito de nuestro producto. Por ejemplo, recientemente he acompañado a un equipo que desarrollaba un producto para una empresa textil. En concreto, este producto se utilizaba por los proveedores para introducir prendas de ropa que iban a fabricar, y los compradores (encargados de hacer los pedidos) revisaban que la información era correcta. La aplicación, bastante antigua, generaba muchos errores en las prendas, lo que provocaba que los compradores tuvieran que rechazar muchas, lo que generaba más trabajo y llamadas al call center. Podemos medir el número de devoluciones que genera nuestra aplicación y asociarle un coste estimativo, de esta manera tendremos un coste aproximado de nuestra aplicación y, si nuestro producto corrige el problema, podremos medir el ROI.

Por tanto, en aplicaciones internas, podemos medir el ROI contrastando el beneficio (métrica de éxito asociada al producto) menos el coste de producto.

Total Cost of Ownership (TCO)

El TCO es una métrica que se utiliza en pocas organizaciones pero sirve para tener una visión clara de los productos. El coste de propiedad fija lo que nos cuesta mantener nuestro producto o evolucionarlo. Es típico que se haga responsable al Product Owner, máximo responsable del coste del equipo, que suele ser el principal coste(directo) de un software. Sin embargo, no suele ser típico hacerle responsable de los costes de la organización (indirectos) o del mantenimiento del producto. Una vez, trabajé en una aseguradora importante que tenían implantado un equipo de mantenimiento, encargado de todas las aplicaciones que ya estaban en producción. Esto permitía que un equipo hiciera mal una aplicación y que el coste de arreglarlo cayera en otro presupuesto. Así es cómo restamos responsabilidad de un equipo y cómo dificultamos hacer Scrum.

Métricas de uso

La métrica de uso está muy poco extendida en la mayoría de organizaciones en las que he trabajado. Tratan de medir cómo es el uso que los usuarios hacen de las características de nuestra aplicación. Algunos ejemplos pueden ser:

• Tiempo que pasan en la aplicación determinados usuarios
• Porcentaje de usuarios que utilizan ciertas funcionalidades
• Recurrencia a la hora de utilizar ciertas características
• Hora a la que hacen uso
• Tiempo por funcionalidad
• Porcentaje de usuarios que abandonan una determinado flujo de trabajo

Con ello, podemos construir un gráfico similar al siguiente que nos compare diferentes funcionalidades de la aplicación:

Que se utilice una funcionalidad no es garantía de éxito, dependerá de su propósito. Por ejemplo, no nos interesa que se utilice la funcionalidad de devoluciones. Sin embargo, en caso de que se use, querremos que sea rápida para minimizar el posible enfado del usuario. Puede haber funcionalidades que se utilizan poco, pero tengan sentido, como un informe mensual de ventas que solo se utiliza un par de veces.

Las métricas de uso en aplicaciones internas suelen ser métricas de éxito. Internamente, nos interesa que se utilicen los software que construimos, mientras que para aplicaciones en el mercado, como un e-commerce, aunque las métricas de uso dan información, el éxito está en el dinero ganado.

Por ejemplo, acompañé hace unos meses a un equipo que desarrollaba un nuevo producto para sustituir uno anterior en desuso. El usuario, descargaba datos en formato excel y trabajaba con ellos, para después subir los cambios a la aplicación. Nuestro objetivo era crear una aplicación que evitara el uso de importaciones en excel (que eran sinónimo de que se habían hecho operaciones con los datos fuera del sistema). Por tanto, nuestra métrica de éxito era el número de importaciones, y nuestra objetivo es que fuera cero. Es un ejemplo de métrica de uso que puede ser éxito.

Este tipo de métricas suelen necesitar de elementos técnicos para medirse, y por tanto, es importante conocerlas en etapas tempranas para que el Development Team puedan desarrollarlas.

Métricas de tiempo

Responder a la pregunta “¿cuándo estará?” es algo crítico en la mayoría de organizaciones. En muchos equipos, se responde a esta cuestión estimando. Sin embargo, la estimación es un dato poco objetivo y que muchas veces se ve influído por la política. Sin embargo, podemos medir el tiempo que tardamos en completar las diferentes funcionalidades o elementos del Product Backlog (PBIs). Para ello, disponemos de tres métricas que están relacionadas según la Ley de Little

CycleTime es el tiempo que tarda el equipo desde que arranca una tarea hasta que la completa. El Delivery Rate es la cantidad de elementos que termina por unidad de tiempo. Y el Work in Progress (WIP) es el número de elementos en los que trabaja a la vez este equipo.

Con el CycleTime medio, podemos hacer construir un scattler plott como el siguiente:

Esta gráfica nos dice que el 90% de los elementos que hemos terminado se realizarán en menos de 2 semanas. De manera que ganamos en predictibilidad y nos permite medir la capacidad de entrega de nuestro equipo.

A diferencia de la velocidad o de los puntos de historia, estas métricas son fácilmente comprensibles por los clientes, hablan su propio lenguaje. Un cliente siempre podrá entender lo que significa “tiempo transcurrido” pero le cuesta entender lo que es “un punto de historia”.

Métricas de servicio

El objetivo de un equipo Scrum es prestar servicio a través del software. Por tanto, medir la calidad de nuestro servicio nos muestra la relación que tiene un equipo con sus usuarios. Tenemos muchas posibilidades a la hora de medir:

• Satisfacción de los usuarios
• Tiempo de incidencias
• Tiempo de resolución
• Estabilidad de la release
• Motivo para hacer release

De todos ellos, me gustaría explicar el último. Durante mi estudio del Professional Scrum Product Owner (PSPO), vimos un dibujo en el que explicaban los diferentes motivos por los que se podía producir una subida a producción. No es lo mismo subir por un fallo grave que hayamos cometido, que por una necesidad detectada recientemente y que queremos cubrir para satisfacer a nuestros usuarios.

Con este modelo, podemos detectar cuándo hacemos una subida “a prisa y corriendo”, para después tener varias subidas de corrección (y mientras estamos dando un mal servicio).

Métricas de equipo

Las métricas de equipo rara vez son de éxito. No obstante, medir la salud del equipo y cómo trabajan le permite a un Product Owner conocer su motivación, pieza clave en el mundo del conocimiento.

Alguna métricas de equipo:

• Número de PBIs terminados por Sprint
• Rotación del equipo (Número de Sprints dónde el equipo ha sufrido un cambio)
• Time2FirstCommit: tiempo transcurrido desde que alguien se incorpora y realiza una subida a producción
• Felicidad del equipo (medida por encuestas)

Para esta última, podemos realizar la siguiente práctica. Cada retrospectiva, le pedimos a los miembros del equipo que evalúen de 1 (malo) a 5 (muy bueno) su opinión con respecto a tres temas: ¿Cómo ha sido el resultado del Sprint?, ¿Cómo ha sido la comunicación del equipo?, ¿Qué tal hacemos Scrum?

Con estas respuestas podemos ver tendencias, y entender cómo está el equipo. Recordemos que una caída en la motivación suele predecir una caída en la productividad del equipo. He visto a muchos Producto Owners interesarse por este tipo de métricas, porque sabían que afectaría a la generación de valor del equipo.

Mide lo que necesitas

Como hemos podido comprobar, existen muchos tipos de medidores. Decidir cuáles aplicar, dependerá del contexto del producto y de la organización. Mi consejo es que, a la hora de arrancar un nuevo producto, no solo invirtamos tiempo en definirlo, sino que hablemos de qué medidores nos dirán si estamos acertando y qué medidores secundarios nos darán también información relevante.

Y tú… ¿Qué métricas usas en tus equipos?