Los puntos de historia constituyen una técnica nacida al calor de la agilidad en sus primeros inicios. Ron Jeffries fue uno de los creadores de los Puntos de Historia y, curiosamente, dijo hace meses que se arrepentía de haberlos inventado. Los puntos de historia son una técnica asociada a la agilidad que mejora la técnica de estimación, pero que nos impide saltar al siguiente paradigma: no necesitar estimar. ¿Son los Puntos de Historia una herramienta Agile?
Agile Estimation and Planning
En el año 2005, Mike Cohn escribió el libro de Agile Estimating and Planning en el que utiliza los puntos de historia como técnica para hacer predicciones en equipos de desarrollo.
Este libro se basa en los Puntos de Historia para diseñar un plan de proyecto y una estrategia de entregables (Plan de Releases). Podemos ver herramientas interesantes como el “Release Burndown”, que permite hacer un seguimiento de una determinada release que va a ocurrir tras varios Sprints. Ahora bien, Mike Cohn asume que eres capaz de predecir todo el trabajo que te queda por hacer y, por tanto, valorarlo en puntos de historia.
Aceptamos que los Puntos de Historia sean una muy buena técnica de estimación, posiblemente la que mejor funciona en un entorno complejo. Ahora bien, sigue siendo muy dudoso que tú puedas saber todo el trabajo que te queda pendiente de realizar ni que, al usar Puntos de Historia, vayas a acertar una determinada fecha. Averiguar todo ese trabajo es un esfuerzo enorme y seguimos conviviendo en el paradigma de las estimaciones por encima de las adaptaciones.
A pesar de que el libro tuvo muy buena acogida, quizás ha hecho daño al sector al seguir prometiendo que éramos capaces de predecir el final de los proyectos cuando los acabamos de arrancar. ¡Justo lo que Agile trata de hacer ver que es imposible en problemas complejos!
Estimar no sirve en Agile
Es muy difícil, en un mundo construido a base de fechas cerradas, hablar de no estimar. Estamos de acuerdo en que ser predecibles es relevante, siempre y cuando esa predictibilidad nazca de datos reales con los que podamos contar. Pero esos datos no pueden ser inventados, no pueden ser una apuesta del equipo ni estar tremendamente condicionados muchas veces. Existen múltiples situaciones donde a un equipo se le recorta la estimación o se duda de ella, lo que hace inútil el trabajo de estimar.
“Usar Puntos de Historia para estimar es como predecir si mañana lloverá haciendo encuestas por la calle” – Jerónimo Palacios
El gran problema del paradigma predictivo es que tomamos decisiones muy importantes antes de arrancar a trabajar con el equipo. Estas decisiones están basadas en datos inventados y poco científicos, ya que parten de la opinión de un equipo. ¿Vamos a tomar decisiones con opiniones o con datos reales?
Adaptación y predictibilidad
Si tenemos que ser predecibles, podremos serlo pasado un tiempo y hayamos ganado experiencia. ¡Cuidado! En el mundo tradicional, se utiliza la técnica de “lecciones aprendidas” como un medio para mejorar nuestras estimaciones, basada en experiencias previas. En Agile buscamos realizar estas predicciones en base a datos y estos solo se obtienen trabajando en el problema complejo que queramos resolver.
Es clave entender que un proyecto pasado no tiene nada que ver con un proyecto futuro, sobre todo en entornos complejos, porque siempre ocurren cambios: el equipo, el cliente, el objetivo, la tecnología…
Los únicos datos fiables que podemos utilizar para mejorar nuestra capacidad de predecir son datos que nacen del equipo actual que tenemos y sobre el trabajo realizado hasta la fecha. Es decir, cuando un equipo lleva tiempo trabajando y medimos su capacidad de entrega, podemos usar este dato para hacer proyecciones de posibles fechas de entrega o de finalización.
Todo esto nos lleva al problema de que no sabemos lo que nos va a costar un determinado proyecto hasta que llevamos un tiempo trabajando en él. Para que un cliente acepte esta situación, tiene que confiar en nosotros y es complejo cuando todavía no hemos generado esa relación de confianza con un cliente nuevo.
Valor por encima de todo
Aunque ser predecible es importante, es mucho más relevante tu capacidad para entregar valor. Un equipo que cumple sus estimaciones o predicciones basadas en datos sigue sin ser un equipo que tenga éxito si no produce valor.
Podemos tener métricas de predictibilidad, pero es más importante tener métricas de valor usadas de manera continua y sobre las que tomemos decisiones. ¡Aquí reside Agile!
Y tú; ¿Tomas decisiones en base a datos o a estimaciones?
Osea sabemos la utilidad de la estimación cuando lleve tiempo el equipo andando y entregando valor? no e sun poco click bait tu artículo?
Una cosa es estimar y otra predecir. Ser predecible en base a datos puede ayudar pero no es exacto. Lo que no podemos es pensar que con puntos o estimaciones somos Agile porque no es su finalidad
Javier, gracias. Aún no me queda claro, si tenemos los datos históricos (promedio) de los compromisos que un equipo puede tomar ¿por qué no usarlos?. ¿Qué usas tú en cambio para determinar a qué puedes comprometerte con un cliente? y ¿qué problemas nos trae/nos puede traer usar los story points? Abrazo.
Recuerda que no existe el compromiso del Sprint, eso lo quitaron hace 12 años. Tu tienes la media de puntos pero es que los puntos son un dato inventado. Es mejor usar el leadtime o el número de PBIs que hacen por Sprint. Esos son datos basados en realidad y no en opiniones