Los puntos de historia son un tipo de técnica de estimación que se utiliza mucho en equipos Scrum para, lógicamente, hacer estimaciones. He acompañado a varias organizaciones para implantar los puntos de historia, incluso en alguna hemos conseguido que pasaran a ser un estándar dentro de la organización. Para el que no conozca la técnica, se la resumo muy rápidamente. Los puntos de historia consisten en fijar una cantidad de trabajo mínima denominada un punto y estimar el resto de tareas que hay que hacer en base a esa cantidad de trabajo.
Por ejemplo, si queremos pintar una habitación de 100 metros cuadrados, el tiempo de pintado dependerá del pintor. Habrá pintores que sean capaces de pintar 50 metros al día y habrá pintores que pinten 20 metros al día. El trabajo es el mismo, el tiempo es relativo a la persona. Los puntos de historia en este ejemplo serían los metros cuadrados. En el mundo del conocimiento no es tan fácil encontrar ese punto porque cada persona tiene experiencias diferentes y conocimientos distintos, y es más complicado llegar a un acuerdo. Sin embargo, los puntos de historia son una buena técnica porque de alguna manera fomentan un debate en torno al trabajo y nos permite ser más realistas que si aplicamos una estimación basada en tiempo (horas o días).
Las estimaciones temporales no tienen sentido, dependen de la persona
Las estimaciones en tiempo son bastante injustas porque dependen totalmente de la persona. Un profesional senior y un junior pueden llegar al acuerdo de que una feature concreta llevará el triple de trabajo que otra, por lo tanto, tendrá el triple de puntos; a pesar de que el experto tardará muchísimo menos que el junior en hacerlos. La estimación en tiempo es muy difícil de ajustar porque ambos entenderán tiempos diferentes; al final, usaremos tiempos medios que son bastante injustos con las personas más novatas.
Los puntos de historia suelen practicarse con la técnica planning póker. El planning poker es una técnica que utiliza la estimación a ciegas. Esto es, cada miembro del equipo realiza su estimación sin conocer la de los demás para, a continuación, mostrarla a sus compañeros y tener un debate sobre el punto de vista de cada uno. Esto permite que cada uno piense sin ser condicionado para que el debate sea más rico.
Los puntos de historia y el planning poker fomentan la conversación, lo que siempre es positivo en un mundo en el que intentamos que los equipos se autoorganicen. En la gestión tradicional, lo que hacemos es asumir que lo que viene en un documento de análisis es lo que tenemos que hacer y, como mucho, que el jefe de proyecto reparta tareas. Pero en Agile, necesitamos tener conversaciones al organizarnos en equipos. De esta manera, podemos gestionar en equipo las expectativas con nuestros clientes y el mercado.
Los puntos de historia sirven para el equipo, no para premiarlo ni castigarlo
El problema viene a la hora de utilizar los puntos de historias como métrica de equipo. Recalco equipo porque asociar puntos de historia de manera individual es una pésima idea. El trabajo es colectivo, habrá personas que hagan pocos puntos porque se dediquen gran parte del tiempo a ayudar a otros compañeros a sacar más trabajo. Por eso, los puntos de historia se miden a nivel de equipo.
La métrica habitual con los puntos de historia es “puntos que completa un equipo por Sprint”. Como métrica tiene muchos problemas porque los puntos son un deseo no una realidad. A pesar de que conversemos, lo analicemos y lo estudiemos, al final damos una estimación. Por tanto, estamos imaginándonos un futuro, pero no lo medimos de manera científica ni fiable.
Si pensamos en el mundo científico, no podemos tener métrica de estimativas de “en tres meses voy a tener la vacuna contra el cáncer”. Lo que hacemos es tener hipótesis y medir lo que va ocurriendo de manera objetiva. Cuando decimos “en este Sprint haremos 60 puntos de historia”, lo que estamos lanzando es una hipótesis de lo que nos gustaría llegar a hacer, una previsión pero no es una realidad.
PBIs por Sprint
Una técnica que he defendido en post anteriores es la de PBIs terminados por Sprint. Este dato nos dice la cantidad que somos capaces de finalizar. Esta métrica se considera retrasada (lagging) en el sentido de que tú no tienes información hasta que no has finalizado el Sprint. No puedes hacer nada en ese momento, pero nos da una información muy interesante de cara a futuros Sprints y, sobre todo, a la tendencia del equipo a ser capaz de hacer más trabajo o menos.
Muchas personas argumentan que esta métrica no es útil porque hay tamaños diferentes de PBI. Es cierto que si tenemos poca homogeneidad, tendremos menos información, sin embargo, nos seguirá funcionando. Los PBIs completados por tiempo siguen la distribución Weibull:
Esta distribución se parece a la normal, pero tiene una característica especial: la cola. La cola marca esos PBIs que se nos escapan, que se disparan en tiempo. Esto puede pasar por multitud de causas: bloqueos, cambios de alcance, alcance poco claro, errores al desarrollarlo etc. Suelen suponer entre el 10-15% de los PBIs que realizamos. Mientras que el resto sí que siguen una distribución normal y nos permiten predecir.
Los riesgos en Scrum
Trabajar en la cola es esencial para que los PBIs no se disparen, y porque esa cola altera nuestros datos. Para saber por adelantado que un PBI puede acabar en esa cola podemos utilizar una métrica adelantada. Si medimos, por ejemplo, los días que nuestros PBIs pasan en el estado “in progress”, podemos tener un buen parámetro adelantado. “Normalmente un PBI pasa tres días en in progress; sieste PBI lleva 5 días, ¡hay que actuar!” De esta manera, podemos utilizar ese medidor adelantado para evitar que los PBIs se disparen y nos impidan cumplir nuestro Sprint Goal.
¿Qué ocurre si el equipo tiende a abrir muchas tareas y a no cerrar ninguna? Este tipo de métrica adelantada nos ayudará a tener conversaciones en torno a esto ¿Por qué no nos centramos en cerrar actividades en vez de seguir abriendo? De esta manera, podemos descubrir qué partes tenemos que mejorar en nuestro equipo.
Por tanto, estos medidores sí que nos indican información real del equipo y nos aportan información con la que tomar decisiones. Recordemos que estamos en un entorno complejo, lo que supone que es difícil ser exactos, pero tener métricas basadas en la realidad nos ayudará a tomar mejores decisiones.
Métricas basadas en valor
Por último, habría que añadir métricas basadas en valor. Medir de alguna manera el valor que aporta nuestro producto. Estas métricas son muy dependientes del contexto y del objetivo para que hagamos el software pero es esencial definirlas y trabajarlas.
Disponer solo de métricas de capacidad del equipo y de cómo rinden es una mala práctica. Nos puede llevar a conclusiones como: este equipo es vago, este equipo ha bajado el delivery, este equipo no funciona. Son discusiones que nos nos interesan porque no giran en torno al valor sino que giran en torno a la eficiencia del equipo. Es importante que el equipo rinda, pero lo más importante es que el producto funcione.
Y vosotros… ¿Cómo medís la capacidad del equipo y su trabajo?
