La Muerte de los Story Points (Y Lo Que Viene Después)

El culto cargo de Fibonacci

Los puntos de historia se han convertido en el culto cargo de la ingeniería moderna.

Los equipos asignan religiosamente números de Fibonacci a los tickets. Discuten sobre si un 3 es realmente un 5. Calculan la velocidad con precisión decimal. Proyectan sprints futuros basándose en promedios históricos. Y luego se preguntan por qué sus predicciones parecen arte abstracto.

Aquí hay una verdad incómoda: los puntos de historia fueron diseñados para un mundo que ya no existe.

La premisa original era simple: los desarrolladores trabajan a velocidades relativamente consistentes, así que medir la complejidad relativa (un 5 es aproximadamente el doble de difícil que un 3) debería producir una velocidad predecible con el tiempo. Establece una línea base y podrás pronosticar con precisión razonable.

Esa premisa ahora está rota.

¿Por qué están muriendo los puntos de historia?

Los puntos de historia asumen una unidad estable: el mismo equipo, trabajando de la misma manera, a aproximadamente la misma velocidad. La asistencia de IA rompió esa suposición de tres maneras: las estimaciones ahora varían enormemente por tarea, la velocidad ya no predice la entrega y las líneas base históricas ya no se transfieren.

El problema de la variabilidad de IA

Cuando el mismo desarrollador puede ser 10 veces más rápido un lunes (con Copilot, una especificación clara y una base de código familiar) que un martes (luchando con un sistema heredado, depurando una alucinación de IA y cambiando de contexto entre tres proyectos), ¿qué significa exactamente una "historia de 5 puntos"?

No significa nada. La unidad de medida se ha vuelto variable.

Considera un ejemplo real: Un desarrollador estima una funcionalidad CRUD en 5 puntos basándose en la velocidad histórica. Con asistencia de IA, la completa en 2 horas. La siguiente historia de 5 puntos implica depurar una condición de carrera en código heredado, donde la IA es inútil, y toma 3 días.

Ambas eran "5 puntos". Una tomó 2 horas, una tomó 24. Tu gráfica de velocidad ahora contiene puntos de datos que varían 12 veces para la misma complejidad estimada.

El problema de la velocidad sin sentido

El informe DORA de 2024 encontró que los equipos que adoptaron asistentes de codificación de IA vieron disminuir el rendimiento de entrega un 1.5% y la estabilidad de entrega un 7.2%¹: más actividad, menos valor entregado. La velocidad mide actividad en lugar de resultados, por eso los equipos con alta velocidad a menudo entregan menos valor que los equipos con velocidad moderada.

Cuando la IA infla las métricas de actividad (más commits, más PRs, más historias "completadas"), la velocidad se convierte en puro ruido. El número sube, pero nadie sabe qué significa.

El problema de la línea base histórica

La estimación de puntos de historia depende de la calibración: "El sprint pasado completamos 40 puntos, así que comprometámonos a 40 este sprint". Pero ¿qué pasa cuando:

• La mitad del equipo acaba de adoptar asistentes de IA (¿la velocidad podría dispararse)?
• La base de código en la que estás trabajando no es familiar para la IA (¿la velocidad podría caer)?
• Tu mejor estimador se fue y se llevó su calibración?

Las líneas base históricas asumen consistencia. La IA destruyó esa suposición.

¿Qué reemplaza a los puntos de historia?

La muerte de los puntos de historia no significa la muerte de la estimación. Tres enfoques funcionan en la era de la IA: experimentos con tiempo limitado, compromisos de resultados y re-estimación continua.

Enfoque 1: Experimentos con tiempo limitado

En lugar de estimar cuánto tiempo tomará algo, comprométete a lo que intentarás dentro de un tiempo fijo.

La forma antigua: "Esta funcionalidad es de 8 puntos, lo que históricamente significa ~4 días".

La forma nueva: "Pasaremos 2 días explorando esta funcionalidad. Al final, sabremos si podemos entregarla o necesitamos más tiempo".

Este enfoque reconoce la incertidumbre por adelantado. No estás fingiendo predecir lo impredecible, te estás comprometiendo a aprender rápidamente.

Enfoque 2: Compromisos de resultados

En lugar de estimar el esfuerzo, comprométete a un resultado para una fecha, y deja que el equipo descubra cómo llegar ahí.

La forma antigua: "Esta épica es de 40 puntos a través de 8 historias, así que tomará 2 sprints".

La forma nueva: "Entregaremos autenticación de usuario para el viernes. Aquí está la versión mínima viable, aquí están los objetivos extendidos y aquí está lo que recortaremos si es necesario".

Este enfoque se centra en lo que importa (resultados) en lugar de proxies (esfuerzo). Crea alineación sobre prioridades y saca a la luz riesgos temprano: "Si no podemos hacer funcionar OAuth para el miércoles, entregaremos solo con email/contraseña".

Enfoque 3: Re-estimación continua

En lugar de estimar una vez en la planificación del sprint y nunca revisitar, actualiza las estimaciones a medida que aprendes.

La forma antigua: "Estimamos 5 puntos en la planificación, así que esa es la estimación".

La forma nueva: "Estimamos 5 puntos el lunes. Para el miércoles sabemos que en realidad es un 8. Esa es información valiosa, actualicemos nuestros compromisos".

Este enfoque trata la estimación como una herramienta para conversación continua en lugar de una predicción única. La estimación evoluciona a medida que crece el conocimiento.

Cómo evoluciona Planning Poker

Construimos nuestra herramienta de Planning Poker para apoyar estos enfoques, no porque pensemos que la estimación tradicional siempre está mal, sino porque los equipos necesitan flexibilidad.

Para estimación tradicional

Sí, aún puedes asignar puntos de Fibonacci. Algunos equipos y algunos tipos de trabajo aún se benefician de la estimación relativa. Bases de código estables, equipos experimentados, dominios bien entendidos: los puntos de historia pueden funcionar aquí.

Pero hemos agregado salvaguardas:

• Detección de anomalías: Las métricas del sprint pasan por detección de anomalías de puntuación z, así que cuando la velocidad oscila fuera de su rango normal lo ves marcado en lugar de enterrado en un promedio.
• Seguimiento de planificado versus completado: Las métricas del sprint comparan a qué te comprometiste con lo que realmente se entregó, así que la deriva de estimación aparece sprint tras sprint en lugar de en el ajuste de cuentas trimestral.
• Tendencias de resultados, no seguimiento de herramientas: Nunca rastreamos quién usó IA en qué. La comparación sprint tras sprint muestra si tus estimaciones se están volviendo más o menos confiables, sea cual sea la causa.

Para experimentos con tiempo limitado

En lugar de asignar puntos, estima en tiempos limitados. La escala de Tiempo (Horas) va de 1 hora a 40, y las escalas personalizadas te permiten definir tus propios puntos de control:

• Spike de 2 horas
• Exploración de medio día
• Prototipo de 1 día

Al final del tiempo limitado, el equipo responde una pregunta simple: "¿Podemos entregar esto, o necesitamos más tiempo?" Esto crea puntos de control naturales sin falsa precisión.

Para compromisos de resultados

Los compromisos de resultados no necesitan herramientas especiales. Define el resultado, establece una fecha objetivo y descompón en hitos con puntos de control de continuar/no continuar. Donde las herramientas ayudan es después: el seguimiento de elementos de acción y las puntuaciones de salud muestran si el compromiso se entregó y se mantuvo.

La conversación es lo importante

Esto es lo que la mayoría de los equipos no entienden sobre la estimación: la estimación en sí no importa. La conversación sí.

Cuando tu equipo discute si algo es un 3 o un 5, el valor no está en llegar al número "correcto". El valor está en sacar a la luz diferentes suposiciones:

• "Creo que es un 3 porque podemos reutilizar el módulo de autenticación existente."
• "Creo que es un 5 porque el módulo de autenticación existente no maneja nuestros nuevos requisitos."

Esa conversación reveló un riesgo. La estimación es casi irrelevante; el entendimiento compartido lo es todo.

Por eso las ceremonias de estimación siguen siendo valiosas incluso cuando las estimaciones en sí son imprecisas. El objetivo no es la predicción. El objetivo es la alineación.

Comunicar el cambio

Si estás convencido de que los puntos de historia tradicionales no están funcionando, necesitarás comunicarlo a las partes interesadas que esperan "tableros de velocidad". Así es como:

Para el liderazgo de ingeniería

Enmárcalo en torno a la previsibilidad, no al proceso. A los líderes les importa saber cuándo se entregarán las cosas. Explica que la velocidad se ha vuelto poco confiable (muestra la varianza), y estás adoptando prácticas que realmente mejorarán la previsibilidad.

Muestra, no cuentes. Ejecuta un experimento paralelo: rastrea la velocidad tradicional Y los compromisos de resultados durante dos meses. Deja que los datos hablen.

Para los socios de producto

Enfócate en lo que les importa: fechas de entrega. A los gerentes de producto no les importan los puntos de historia—les importa saber cuándo estarán listas las funcionalidades. Los compromisos basados en resultados les dan mejor información: "Entregaremos el viernes" es más útil que "Completamos 40 puntos."

Hazlo sobre la identificación de riesgos. La reestimación continua identifica riesgos más temprano. Eso es lo que producto necesita: advertencia temprana, no confianza falsa.

Para el equipo

Reconoce la disfunción. Si los puntos de historia se han convertido en un ritual vacío, el equipo lo sabe. Admitirlo genera confianza.

Hazlo opcional inicialmente. Deja que el equipo experimente con alternativas en algunas historias antes de comprometerse con una transición completa.

El futuro de la estimación

Hacia aquí nos dirigimos:

Corto plazo: La estimación se vuelve adaptativa. Los equipos usan diferentes enfoques para diferentes tipos de trabajo: puntos de historia para trabajo estable y bien entendido; cajas de tiempo para exploración; compromisos de resultados para funcionalidades de alta prioridad.

Mediano plazo: La IA asiste con la estimación misma. Basándose en patrones históricos, análisis de complejidad del código base y trabajo pasado similar, la IA puede sugerir estimaciones—no como verdad, sino como entrada para la conversación.

Largo plazo: La estimación se vuelve menos necesaria. A medida que los ciclos de despliegue se comprimen y los ciclos de retroalimentación se ajustan, la necesidad de predicción anticipada disminuye. Sabrás si algo es difícil trabajando en ello durante unas horas, no debatiendo puntos en una reunión de planificación.

Los puntos de historia nos sirvieron bien durante dos décadas. Fueron la herramienta correcta para su tiempo. Pero las condiciones que los hicieron útiles han cambiado fundamentalmente, y nuestras prácticas necesitan cambiar con ellas.

Qué significa esto para tu equipo

Si estás sintiendo disfunción con los puntos de historia, no estás solo. Aquí es donde empezar:

1. Mide la varianza de tu velocidad. Si fluctúa más del 25% de sprint a sprint, tus estimaciones no son predictivas; son ruido.

2. Prueba una alternativa. Elige algunas historias en el próximo sprint y estímalas con cajas de tiempo en lugar de puntos. Ve cómo se siente.

3. Enfócate en resultados. Al planificar, pregunta "¿Qué queremos que sea verdad al final del sprint?" en lugar de "¿Cuántos puntos podemos completar?"

4. Acepta la incertidumbre. La respuesta honesta a "¿Cuánto tiempo tomará esto?" a menudo es "Aún no lo sé—déjame intentarlo durante un día y te diré más."

El objetivo nunca fue asignar el número correcto. El objetivo fue entregar software valioso. Si tus prácticas de estimación están obstaculizando ese objetivo, es hora de que evolucionen.

Fuentes