FIBONACCI EN AGILIDAD: POR QUÉ MUCHAS ORGANIZACIONES TERMINAN CONVIRTIENDO LOS STORY POINTS EN DÍAS

1. Introducción — El momento donde Fibonacci empieza a perder sentido

Durante la estimación de historias de usuario, me ha pasado en distintos proyectos escuchar razonamientos que, sinceramente, al inicio incluso parecen lógicos. Uno de los más comunes es cuando alguien menciona algo como:

“Si un developer hace aproximadamente 13 puntos por sprint, entonces un equipo de 5 developers debería entregar 65 puntos”.

Y normalmente no lo dicen como una opinión o aproximación. Lo dicen con bastante seguridad, como si realmente Fibonacci hubiese sido diseñado para representar productividad matemática exacta.

Ahí comienzan los problemas con las estimaciones ágiles. Porque Fibonacci nunca nació para calcular capacidad exacta, ni productividad individual, ni velocidad matemática predecible. Sin embargo, en muchos entornos termina utilizándose justamente para eso.

El resultado es que los Story Points empiezan a convertirse nuevamente en horas, días o métricas de rendimiento disfrazadas, aunque originalmente buscaban representar algo completamente distinto.

Lo interesante es que esto no ocurre porque las organizaciones “no entiendan agilidad”, sino porque fuera del equipo existe una necesidad real de forecasting, reporting, capacidad, presupuestos y compromisos.

El problema aparece cuando intentamos convertir el trabajo del conocimiento en algo completamente lineal y predecible, aun cuando en los proyectos reales rara vez se comporta así.

2. ¿Por qué usamos Fibonacci en agilidad?

El objetivo detrás de Fibonacci es representar algo que ocurre constantemente en proyectos reales: el esfuerzo no crece de forma lineal conforme aumenta la complejidad del trabajo.

La lógica detrás de Fibonacci no intentaba decir que una historia de 2 puntos toma exactamente el doble que una de 1. Lo que buscaba representar era que, mientras aumenta el tamaño del trabajo, también aumenta la incertidumbre, el riesgo, las dependencias, la dificultad para comprender todos los escenarios posibles y la probabilidad de encontrar problemas inesperados durante la ejecución.

Y esto en los proyectos se vive constantemente.

Una historia pequeña normalmente tiene un alcance bastante entendible, pocas dependencias y un contexto relativamente controlado. Pero conforme el trabajo empieza a crecer, también aparecen más validaciones, más equipos involucrados, más aprobaciones, más conversaciones, más reglas de negocio y más escenarios difíciles de prever desde el inicio.

Por eso Fibonacci terminó encajando en agilidad. Porque intenta representar complejidad relativa en un entorno donde el trabajo cambia constantemente y donde la incertidumbre tiene un impacto enorme en la ejecución real, y esto no tiene nada que ver con representar tiempo exacto.

3. Lo que realmente ocurre dentro de los proyectos

Desde fuera del equipo puede parecer lógico pensar que una historia de 2 puntos debería equivaler aproximadamente al doble de esfuerzo que dos historias de 1 punto. El problema es que en proyectos reales las cosas rara vez funcionan de esa manera.

Una historia de 1 punto puede ser un cambio bastante aislado, entendible y sin demasiadas dependencias. Pero una historia de 2 puntos puede involucrar integraciones con otros sistemas, coordinación con otro equipo, validaciones funcionales adicionales, pruebas integradas, aprobaciones o incertidumbre técnica que todavía no está completamente clara al momento de estimar.

Y conforme el tamaño sigue creciendo, el comportamiento empieza a alejarse todavía más de cualquier lógica lineal.

Tener en cuenta que una historia grande no se vuelve compleja únicamente porque tenga más líneas de código. En si pasa porque empiezan a aparecer problemas alrededor del trabajo:

• APIs que no han sido validadas por Gobierno de API

• dependencias bloqueadas

• reglas de negocio ambiguas

• QA integrado

• aprobaciones externas

• cambios de prioridad

• equipos que responden tarde constantemente

Por eso muchas veces el verdadero esfuerzo del proyecto no está únicamente en desarrollar. Está en coordinar, validar, entender y estabilizar todo lo que rodea al desarrollo.

Y justamente eso es lo que Fibonacci intenta reflejar cuando usamos Story Points en entornos ágiles.

4. ¿Por qué en algunas organizaciones deforman la estimación de Story Points?

Con el tiempo, muchas organizaciones terminan intentando convertir los Story Points nuevamente en algo completamente matemático y predecible. Y sinceramente, es bastante entendible por qué ocurre.

Las organizaciones necesitan planificar presupuestos, generar forecastings, proyectar capacidades, calcular fechas, construir roadmaps y reportar avances a distintos niveles de management.

El problema es que, para poder hacer eso, normalmente se necesita transformar la incertidumbre del trabajo en números mucho más estables y predecibles.

Y ahí comienzan a aparecer equivalencias como:

• “1 punto equivale a 1 día”

• “Este developer suele hacer 13 puntos”

• “Este equipo debería hacer exactamente 40 puntos”

• “Otro equipo hace más velocidad”

Aparecen los problemas cuando empezamos a asumir que el trabajo del conocimiento funciona como una fábrica lineal donde el esfuerzo siempre crece de forma proporcional.

Ya que cuando los Story Points empiezan a utilizarse como métricas de productividad exacta, el equipo deja de estimar complejidad y empieza a estimar “políticamente correcto”.

Se deja de hablar de incertidumbre y las conversaciones empiezan a centrarse en defender capacidad, justificar velocidades o evitar cuestionamientos sobre productividad.

Ahí se pierde el propósito de los Story Points con el que originalmente se crearon.

5. ¿Por qué desde fuera del proyecto desean que el trabajo se visualice de forma lineal?

Aquí es importante entender algo que muchas veces desde agilidad no se menciona lo suficiente:

Fuera del equipo sí existe la necesidad obligatoria de tener números más predecibles.

PMOs, Product Managers, managers, áreas financieras o responsables de portfolio necesitan construir planes, compromisos, presupuestos y reportes.

Necesitan responder preguntas como:

• ¿Cuándo estará listo?

• ¿Cuánta capacidad tenemos?

• ¿Qué podremos entregar este trimestre?

• ¿Qué tan retrasados estamos?

Y para poder responder eso, ellos necesitan transformar el trabajo en algo mucho más lineal y gobernable.

El problema es que el trabajo del conocimiento no siempre coopera con esa necesidad.

Porque una historia aparentemente sencilla puede terminar creciendo enormemente debido a incertidumbre, dependencias o problemas que nadie veía al inicio.

Fibonacci incomoda porque recuerda constantemente que el trabajo real no siempre se comporta de forma proporcional o perfectamente predecible.

El error que cometen muchas organizaciones es simplificar el trabajo de los equipos para que cuadre mejor con reportes, forecastings o modelos de capacidad.

Y ahí comienzan los problemas cuando esa simplificación termina desconectándose demasiado de cómo realmente se comportan los proyectos durante la ejecución diaria.

6. El verdadero problema no es Fibonacci

El problema aparece cuando intentamos usar los Story Points para lo que no se busca representar.

El verdadero problema comienza cuando Fibonacci se utiliza como métrica de productividad, capacidad exacta o rendimiento individual.

Las estimaciones dejan de reflejar incertidumbre real y comienzan a ajustarse para protegerse políticamente.

Los equipos empiezan a:

• inflar puntos

• evitar riesgos

• dividir historias artificialmente

• mantener velocidades esperadas

Y lo más curioso es que muchas veces eso termina generando el efecto contrario al que buscaban las organizaciones.

Porque terminamos forzando precisión matemática justamente donde estamos intentando medir incertidumbre.

Eso acaba convirtiendo los Story Points en métricas aparentemente exactas, pero cada vez menos conectadas con la complejidad real del trabajo.

7. Lo que quiero que te lleves…

Fibonacci termina incomodando en algunos entornos porque nos recuerda que el trabajo del conocimiento no siempre crece de forma lineal, aunque las organizaciones necesiten representarlo así para poder gestionarlo.

Ahí aparece una tensión entre cómo realmente se comporta el trabajo dentro de los equipos y cómo las organizaciones necesitan visualizarlo para tomar decisiones, proyectar capacidad o construir compromisos.

Nunca olvidemos que detrás de cualquier estimación existe incertidumbre, y que intentar eliminarla completamente muchas veces no hace que el proyecto sea más predecible… solo hace que las métricas se alejen cada vez más del día a día que viven los equipos dentro de los proyectos.

Gracias a todos los que llegaron hasta el final. Si tienen alguna sugerencia de algún tópico que tocar, pueden dejarmelo como sugerencia aquí abajo.