Agile Delivery: No es buena idea medir la productividad de los equipos con Velocity en Story Points

¿Cómo medimos la productividad TI de nuestros equipos ágiles? ¿Y si usamos Velocity? Y, como nuestros equipos trabajan con Scrum… ¿Si usamos Story Points? mmmmm... ¡NO! Usar puntos de historia o días ideales para medir la productividad es una muy mala idea (es como medir líneas de código). Claro que parece lo más fácil, pero será definitivamente una fórmula para el desastre. Vamos a hacer que los equipos bajen su rendimiento. ¿Por qué? Por lo siguiente: 

1. Generará inflación y engaño: Hará que los equipos comiencen a inflar gradualmente el significado de un punto, perjudicando su estimación y degradando su trabajo. Recordemos que los puntos de historia son valores relativos, como una moneda, como el dólar. Si nos van a premiar por entregar más pesos, el equipo va a sentirse motivado y presionado para entregar los mismos dólares pero más pesos. Van a generar inflación. Quiere decir que un equipo inteligente, se dará cuenta de que si inflan gradualmente sus estimaciones en el transcurso de un año, alcanzarán su objetivo o incluso lo superarán, SIN entregar más valor a la organización. 
2. Sacará el foco metodológico de Scrum: El aumento de la velocidad no es el objetivo de scrum, sino que es entregar software funcionando, valioso y de alta calidad al cliente de una manera sostenible. Querer entregar más puntos les saca el foco. Puede hacer también que comiencen a contabilizar puntos por cualquier cosas: por hotfix, por spikes, por trabajos de research, etc. 
3. Disminuye la calidad: por la presión o necesidad de aumentar la velocidad los equipos harán concesiones para completar las historias adicionales necesarias para obtener los números más altos. Por entregar más dejarán de prestar atención a la calidad. Introducirán deuda técnica. Es decir que la calidad sufrirá inevitablemente cuando se toman este tipo de decisiones. Puede influenciar a bajar la vara de la definición de Terminado DoD para poder liberar puntos más fáciles. 
4. Frena el aprendizaje: Si el equipo de scrum aprende algo nuevo sobre una historia, la velocidad puede subir o bajar dramáticamente. Los Story Points varían durante la madurez del equipo. El equipo no debe alterar el trabajo de aprendizaje hecho al estimar honestamente. Al motivar la velocidad por puntos de historia se penaliza el fallo, lo cual degrada el aprendizaje. El equipo no querrá fallar. Una estimación puede estar muy lejos de la realidad, es una ESTIMACIÓN. Fallar estimando sirve para aprender. Por otro lado el equipo no va a querer dejar tiempo para investigar o innovar, ya que ese tiempo lo pueden gastar en hacer puntos. 
5. Generar competencia entre equipos en vez de colaboración: Cuando se miden puntos se suele caer en un intento de normalizar la velocidad entre varios equipos de scrum. Esto también es una muy mala idea. Esto puede hacer que los equipos se peleen por los puntos y a veces no quieran colaborar en puntos de otros equipos. Es una comparación sin sentido ya que los equipos de scrum tienen diferentes habilidades, objetivos, herramientas y enfoques para estimar el trabajo. Los Story Points son una métrica interna del equipo que le sirve para mejorar y autogestionar su trabajo. 
6. Puede generar culto, miedos y odios a Scrum: hay equipos que podrían usar el Método Kanban en vez de Scrum y no usar Story Points y ellos se verían afectados. Y otros pueden llegar a odiar Scrum si lo ven como herramienta de presión y estrés.

Por último, recomiendo reflexionar acerca de... ¿Por qué queremos medir la productividad de los equipos? McGregor nos decía con su Teoría X que hay gerentes o subgerentes que piensan que: “a los empleados no les gusta el trabajo, hay que obligarlos, controlarlos, amenazarlos o incentivarlos para conseguir metas”. Esta idea puede llevar a medir y controlar a la gente. En cambio, en agilidad no es esa la idea. Jurgen Appelo nos dice en Management 3.0 que: debemos gestionar al sistema no a la gente. Sumando la Teoría Y (de McGregor) a gerentes, debemos asegurar las personas correctas, liderar, formar, desarrollar competencias, hacer crecer la estructura, facilitar el trabajo, generar condiciones, asegurar infraestructura y facilitar recursos para que los equipos desarrollen software de calidad y de valor. Las personas se dirigen y se autocontrolan si están comprometidas con los objetivos. Los desarrolladores se pueden convertir en personas que desarrollen productos extraordinarios, en equipos de alto rendimiento; si tienen la libertad de desarrollar su potencial y las condiciones necesarias para desarrollar un propósito.

O sea, finalizando, la premisa es: “gestionar el Sistema y no a la gente”. Y si gestionamos el sistema de desarrollo de software de los equipos, entonces necesitaremos medir rendimiento de nuestro sistema de desarrollo de software compuesto por nuestros equipos y su infraestructura. Para eso desde el punto de vista de NEGOCIO deberíamos usar KPIs de negocio que indique la entrega de valor; y para la perspectiva DELIVERY TI (tecnología) son recomendables otras métricas de Performance, no Velocity con Story Points.
En próximas notas recomendaré KPIs de Performance.

Saludos.

Referencias:

• Should Companies Measure Productivity in Story Points / Ideal Days?
• SCRUM: VELOCITY MEASURES STORY POINTS, NOT PRODUCTIVITY.
• Is It a Good Idea to Establish a Common Baseline for Story Points?
• Jurgen Appelo - ManageMent 3.0 - Leading agile Developers, Developing agile Leaders.
• Douglas McGregor (1960), “El lado humano de las organizaciones”.