Uno de los errores más comunes que cometen aquellos que hacen Scrum es pensar que el Framework es el objetivo en sí mismo y lo importante es ceñirse a los eventos, role y artefactos. No podrían estar más equivocados. Si hay que reducir Scrum a una sola cosa, es entregar un incremento de software, terminado, que genere valor.
Aquellos que practican Scrum olvidan que el artefacto más importante es entregar un incremento de software potencialmente liberable al final de cada Sprint. Y el Product Owner es responsable de decidir cual es este incremento a través del Product Backlog y tiene que medir su generación de valor.
Esta semana he impartido el curso de Professional Scrum Product Owner en Madrid, y este fue uno de los temas que más tocamos como parte del trabajo del Product Owner y la labor del Scrum Master en asesorarle.
Construir software es muy caro, y a pesar de ello la mayoría de las compañías son incapaces de medir o predecir el valor que su software produceExisten muchas formas de medir valor, pero lo más importante es que exista un método a priori en la organización para hacerlo. Los famosos KPIs. Algunas empresas tienen en cuenta la facturación de su producto, mientras que otras tienen en cuenta que el número de bugs sea mínimo. Otras tienen en cuenta el Time to Market mientras que otras tienen en cuenta el beneficio por empleado. Lo importante no es cual sea la métrica, sino que esta métrica refleje el valor generado para la organización y el equipo Scrum sea consciente de ello. Las métricas tienen que definir a priori. Por ejemplo, EBMgt define tres grandes métricas compuestas de cuatro submétricas más pequeñas. Time to Market, Actual Value e Innovation Rate
Muchos equipos Scrum no tienen idea de cual es la razón por la que hacen su trabajo. ¿Satisfacer al cliente? ¿Hacer lo que el cliente pide? Me vienen muchos ejemplos a la cabeza en los que se puede hacer todo lo que el cliente pide y que al final se sienta totalmente descontento. Incluso peor. Equipos que desarrollan productos a los que nadie en la organización presta atención. No tienen valor alguno y nadie quiere plantearse por qué se hacen o dejan de hacer. No es lo que queremos conseguir con Scrum.
Net Promoter Score
Si no tenéis una métrica concreta, mi sugerencia es que empecéis por usar el Net Promoter Score. El NPS® se basa en una pregunta muy sencilla, preguntarle a vuestro clientes: ¿Del 1 al 10, cómo recomendarías nuestro(s) producto(s)?
Todos los que respondan 1 a 6 se convierten en detractores, aquellos que respondan 7 u 8 son neutrales, y aquellos que responden 9 o 10 son promotores. Si restamos el número de detractores al número de promotores y nuestro NPS® es positivo… ¡Estamos generando valor! En general un NPS® de más de 50 es un indicador positivo de crecimiento. Puedes leer más sobre esta métrica aquí.
Por supuesto, el NPS es una métrica más, que hay que tomar con cautela. Cada vez que marcamos una métrica como objetivo, el sistema tiende a falsificarla. Sin embargo, es una manera barata y sencilla de empezar a medir el valor que genera vuestra organización. ¿A que esperas para ponerla en marcha?
