Producto, Scrum

8 Errores al usar Puntos de Historia

Los puntos de historia nacieron de eXtremme Programming gracias a Ron Jeffries. Mike Cohn los popularizó en su obra Agile Estimating and Planning, un libro que ha podido hacer mucho daño al concepto actual de Agile de muchas empresas. Los puntos de historia siguen generando un gran debate en la agilidad y muchos equipos los usan de manera incorrecta, convencidos de que son ágiles. Analizamos errores comunes que hemos cometido todos. 

Creer que son Agile

Agile nace como una alternativa al modelo tradicional cascada en el que tratamos de planificar todo el trabajo antes de comenzar. Agile tiene un enfoque adaptativo, en vez de predictivo. Es decir, con Agile, tratamos de arrancar pronto e ir tomando decisiones en base a datos según los vamos obteniendo. 

Agile se basa en adaptarnos en vez de en predecir. Los puntos de historia son una técnica predictiva. Al nacer al calor de eXtremme Programming, una de las técnicas más “puras” en el mundo Agile, relacionamos su uso con la agilidad. Sin embargo, el desarrollo ágil de software se basa en evitar predecir todo antes de arrancar, algo que los puntos refuerzan. La diferencia es que, en vez de usar horas o días, usan puntos para marcar el trabajo. Coincido en que puede ser la mejor técnica de estimación, pero sigue siendo eso, estimación. Si necesitamos estimar antes de arrancar… ¿Dónde está el verdadero cambio que pide Agile? 

los puntos de historia no son científicos y exactos

Pensar que son datos científicos

Como leía en el libro The Professional Product Owner, la medicina lleva 2900 años tratando a personas, pero solo 100 usando datos reales. En los 2800 anteriores, se cometieron tropelías como beber Mercurio o usar aceite de serpiente. Los autores del libro proponían usar datos científicos (empíricos) para tomar decisiones, en vez de usar datos estimativos, que son inventados. 

Como decía Jerónimo Palacios, Scrum Trainer, “estimar en puntos de historia es como predecir el tiempo atmosférico haciendo encuestas por la calle”. Y es cierto que hacer una encuesta por la calle sobre si mañana llueve nos dota de datos, pero no significa que esos datos sean fiables ni científicos. 

Los puntos de historia son un estándar dentro de un equipo, pueden ser útiles, pero no podemos pensar que con ellos vamos a predecir el futuro de nuestro producto, el gran deseo de los métodos tradicionales y por lo que fallan en entornos complejos. 

Puntos de historia cambiado por horas

Muchos equipos dicen “usamos puntos de historioa, un punto son 8 horas”. Antiguamente, en la España pre-euro, existía una moneda: la peseta. La peseta se podía unir en grupos de cinco, lo que se conocía como “duros”. Por ejemplo, 100 pesetas equivalían a 20 duros. Es más, existía un dicho que versaba: “Nadie da duros a cuatro pesetas”. Pues bien, los duros y las pesetas son lo mismo: es dinero contado de maneras diferentes. Si en nuestro equipo existe una equivalencia entre puntos y horas, entonces son horas. 

Los puntos de historia representan “cantidad de trabajo”. Imaginemos que hay que pintar una habitación de 100 metros cuadrados. ¿Cuánto tiempo se tarda? Depende del pintor: si un pintor es capaz de pintar 50 metros al día, tardará dos. Por contra, un pintor que hace 20 metros al día, necesitará cinco días. El trabajo que hay que realizar es el mismo, pero el tiempo depende de la persona que lo haga. El metro cuadrado sería un punto de historia.

Los equipos deben fijar su “metro cuadrado” que le sirva de referencia para modelar el trabajo que tienen que acometer. Ahora bien, es mucho más complejo definir ese punto en entornos del conocimiento que en la pintura. 

Tratar de buscar la exactitud

Muchos equipos desean ser predecibles. Vivimos en un mundo de control donde queremos saber en qué se invierte el tiempo. Además, llenamos las empresas de mecanismos de control sobre equipos del conocimiento que se enfrentan a problemas cuya solución no es trivial. 

Los puntos de historia evitan la exactitud. El Project Management Institute defiende que cuando estimamos en horas, demos márgenes de error. Es más, se propone que, ante un cálculo de fecha, se asocie un Plan de Riesgos que lo puede hacer variasr. Los puntos de historia no persiguen la exactitud, es más, hay quienes lo aplican como órdenes de magnitud. Por ejemplo, pueden existir dos trabajos estimados en cinco puntos y que uno de ellos tenga una duración superior. 

Incluso, hay equipos que usan puntos de historias exactos, del tipo “este trabajo son 3,2 puntos de historia”. Este tipo de actitudes nos recuerdan al problema anterior, puntos por horas. 

Usar medias de puntos de historia

Otro error típico y más difícil de entender es el uso de las medias para estimar. Este error no solo afecta a las horas, sino también a los puntos de historia. Cuando estimamos, usar medias es peligroso porque es raro que nuestra predicción coincida exactamente con la media. Recordemos que la media debe ir acompañada, como mínimo, de la desviación típica, que aporta precisión a la media. Si en una habitación decimos que hay “una media de treinta años”, pensamos en un par de personas jóvenes. Sin embargo, podría haber una abuela de sesenta años con su nieto recién nacido. La media es la misma pero la desviación es mayor en el segundo ejemplo. 

Usar medias es peligroso para las expectativas. Podemos prometer fechas que, muchas veces, no se cumplirán. Es mejor estrategia usar el percentil-90, es decir, lo que ocurre el 90 por ciento de las veces. Por ejemplo, en vez de decir que tardamos una media de siete días, decir que tardamos díez días o menos con una probabilidad del 90 por ciento. ¡Nos da más seguridad! 

no se deben comparar equipos con puntos de historia

Comparar equipos con puntos de historia

Este es el fallo más típico aunque ya superado en muchas empresas. Dado que a las empresas les encanta el control, muchas optan por comparar puntos de historia entre equipos. Como vimos antes, cada equipo define su punto y, por tanto, no se pueden comparar. Un equipo puede que haga 300 puntos, mientras que otro solo haga cinco. Dependerá de la cantidad de trabajo que se determine de un punto. 

Si a esto sumamos que no son horas, no son exactos, y las medias no son buenas amigas. Comparar equipos puede provocar muchas situaciones injustas y más enfados que realidades positivas. 

Puntos día/trabajador

Al calor de la exactitud de los puntos, algunos equipos intentan calcular los puntos por persona y día. Los puntos de historia se suelen aplicar a nivel de equipo, porque representan el resultado del trabajo del mismo. Ahora bien, ¿qué hacemos con Sprints donde hay vacaciones? 

He visto a equipos calcular cuántos puntos de media hace un developer de un equipo para calcular cuántos haremos en el siguiente Sprint, si algunas personas están de vacaciones o ausentes. Por ejemplo, calcular 8 puntos / persona / día, y usarlo para multiplicar por el número de días disponibles del equipo. 

Si un equipo quiere saber lo que será capaz de hacer en un Sprint, la mejor manera es hablarlo como grupo, no basarnos en unos puntos que, insisto, nos hemos inventado. 

Obsesionarse con ellos

Es curioso, muchas personas me han preguntado sus dudas sobre los puntos de historia. Muchas de esas dudas están relacionadas con varios de los puntos que hemos tratado en este artículo. Ahora bien, casi nadie me ha preguntado por la verdadera preocupación de un equipo: ¿alguien quiere nuestro producto? ¿pagarían por ello? ¿lo recomendarían? ¡Estas deberían ser las verdaderas preocupaciones de un Scrum Team!

Los puntos de historia son buenos porque generan una conversación, sirven para analizar el trabajo que tenemos delante y organizarnos. Muchos equipos se obsesionan tanto que, en la Sprint Planning, solo se dedican a decir una cifra, en vez de pensar, como equipo, en los retos y las expectativas que tienen delante. 

La auténtica propuesta de Scrum es pensar en valor, en centrarnos en resultados, y los puntos de historia no son resultados. 

Y tú, ¿cuáles de estos fallos has cometido? 

2 comentarios sobre “8 Errores al usar Puntos de Historia”

  1. No puedo estar en mas desacuerdo con este articulo (por primera vez) y da una visión de no estar en el mundo práctico y real del desarrollo en el punto actual en que nos encontramos.

Deja un comentario