Para investigar esta cuestión, Saint Jude analizó 727,282 issues de Jira, distribuidos entre 204 proyectos de software y 19 dominios diferentes. Comparamos los story points con datos reales de entrega para entender si proyectos que utilizaban estimaciones similares también presentaban comportamientos similares durante la ejecución. El objetivo no era partir de la opinión de que los story points funcionan o no funcionan, sino observar qué ocurre cuando una estimación relativa empieza a utilizarse como si fuera una métrica estandarizada de entrega de proyectos.

El resultado muestra una diferencia importante entre estimar una actividad y medir el comportamiento de un proyecto. Los story points pueden tener sentido dentro de la referencia creada por un equipo, pero eso no significa automáticamente que los mismos valores puedan compararse entre equipos, proyectos o portafolios diferentes.

Story points en horas: por qué esta conversión se convierte en un problema

Los story points en Scrum y Agile se utilizan para representar diferencias relativas entre actividades. Muchos equipos utilizan una secuencia similar a Fibonacci — 1, 2, 3, 5, 8 y 13 — para expresar diferencias de complejidad, incertidumbre y esfuerzo esperado. Lo más importante es que estos valores tienen sentido en relación con otras actividades estimadas por el mismo equipo. Una actividad de cinco puntos se interpreta como más compleja, incierta o exigente que una actividad de tres puntos dentro de esa misma referencia.

La dificultad comienza cuando esta escala relativa se convierte en tiempo. Es común escuchar preguntas como cuántas horas corresponden a un story point, si cinco puntos representan uno o dos días de trabajo o cuántos story points deberían completarse durante un sprint. Estas preguntas son comprensibles porque los responsables de proyectos necesitan trabajar con fechas, capacidad y previsiones de entrega, pero el propio concepto de story point no establece una conversión universal entre puntos y horas.

Un equipo puede completar históricamente cierto tipo de actividad de cinco puntos en pocos días, mientras que otro puede utilizar los mismos cinco puntos para clasificar un trabajo que necesita mucho más tiempo. La story point estimation funciona a partir de la referencia construida por el equipo y no de una escala común utilizada por todas las organizaciones.

Si fuera posible convertir los story points en una métrica estandarizada de entrega, los proyectos que utilizan valores similares deberían presentar tiempos de ejecución al menos razonablemente cercanos. No sería necesario que todas las actividades tardaran exactamente lo mismo, porque cualquier proyecto presenta variaciones, pero deberíamos encontrar una relación suficientemente consistente como para utilizar esos puntos como referencia común. Fue precisamente ahí donde los datos comenzaron a mostrar un comportamiento diferente.

Qué revelan los story points en Jira sobre el cycle time real

Comenzamos observando proyectos cuya mediana de story points era exactamente uno. Esta comparación ofrece una referencia sencilla: si el número uno tuviera un significado razonablemente consistente entre proyectos independientes, sus medianas de cycle time no deberían estar completamente desconectadas entre sí.

Sin embargo, encontramos exactamente lo contrario. Proyectos con la misma mediana de story points presentaban tiempos medianos de entrega radicalmente diferentes.

Proyecto Mediana de story points Mediana de cycle time Proyecto 1 1 0.7 horas Proyecto 2 1 115.5 horas Proyecto 3 1 161.9 horas Proyecto 4 1 197.4 horas Proyecto 5 1 4,464.8 horas Proyecto 6 1 8,246.3 horas

Todos estos proyectos presentan la misma mediana de estimación, pero sus medianas de cycle time son extremadamente diferentes. En un extremo, la mediana es inferior a una hora. En el otro, supera las 8,000 horas. Incluso cuando dejamos de lado los valores más extremos y observamos solamente los proyectos intermedios, todavía encontramos diferencias suficientes para mostrar que el número uno no tiene un significado estandarizado de entrega entre proyectos.

Para mí, este es uno de los puntos más importantes del análisis. Un story point puede tener sentido dentro del historial del equipo que lo creó, pero cuando retiramos ese número de su contexto nos dice muy poco sobre cuánto tiempo debería tardar realmente una actividad. La estimación continúa existiendo, pero la referencia que daba significado a ese número desaparece.

El mismo patrón aparece cuando aumentan los story points

La diferencia no ocurre únicamente con actividades estimadas en un punto. Los proyectos con una mediana cercana a tres story points también presentaron cycle times bastante diferentes. En uno de los proyectos analizados, la mediana de entrega fue de aproximadamente 120 horas. En otro llegó a casi 292 horas. Un tercer proyecto alcanzó aproximadamente 454 horas, aun utilizando la misma mediana de story points.

Esto se vuelve especialmente relevante cuando los story points salen del contexto del equipo y pasan a formar parte de la gobernanza de proyectos. Un PMO puede observar diferentes boards de Jira y encontrar el número tres en todos ellos, interpretando esas actividades como si fueran comparables. En la práctica, cada equipo puede haber creado esa estimación utilizando referencias históricas, niveles de experiencia, arquitecturas, tecnologías y criterios completamente diferentes.

El problema, por lo tanto, no está necesariamente en utilizar story points para estimar una actividad. El problema aparece cuando asumimos que la escala continúa siendo comparable después de atravesar las fronteras entre equipos y proyectos. El número sigue pareciendo objetivo, pero el contexto que explicaba ese número ya no es el mismo.

Más story points no significan automáticamente un cycle time mayor

Otra parte de los datos hace esta diferencia todavía más evidente. Encontramos proyectos con una mediana de cinco story points cuyo cycle time mediano era significativamente menor que el de proyectos que utilizaban una mediana de apenas un story point.

En uno de los casos, un proyecto con una mediana de cinco puntos presentaba un cycle time de aproximadamente 140.5 horas. Otro proyecto, utilizando una mediana de un punto, superaba las 2,000 horas. En otra comparación, un proyecto con una mediana de tres puntos presentaba aproximadamente 120 horas de cycle time, mientras que otro, con una mediana de apenas un punto, superaba las 4,400 horas.

Esto no significa que una actividad de cinco puntos sea naturalmente más rápida que una actividad de un punto. Sería incorrecto interpretar el resultado de esa manera. Lo que muestran los datos es que los valores absolutos de story points procedentes de proyectos independientes no forman una escala común de tiempo.

Cada equipo construye su propia referencia de estimación. Si esa referencia se utiliza de forma consistente, los story points pueden seguir ayudando al equipo a discutir complejidad relativa y planificar sus sprints. Pero cuando combinamos varios equipos y tratamos los valores como si todos pertenecieran a la misma escala, creamos un nivel de comparabilidad que los datos analizados no respaldan.

Por qué la story point estimation resulta difícil de comparar entre equipos

Imagina una organización con tres equipos de desarrollo. El Equipo A completa 80 story points durante un sprint, el Equipo B completa 45 y el Equipo C completa 110. Cuando esos números aparecen juntos en un dashboard ejecutivo, la interpretación más inmediata puede ser que el Equipo C entrega más y el Equipo B entrega menos.

El cálculo es matemáticamente correcto, pero la conclusión depende de una suposición importante: los tres equipos tendrían que utilizar escalas equivalentes de estimación. Los story points, sin embargo, no fueron creados para garantizar esa equivalencia. Una historia que recibe cinco puntos en un equipo podría recibir tres u ocho en otro, dependiendo de la complejidad técnica, la arquitectura, la experiencia del equipo, el nivel de incertidumbre e incluso los hábitos de estimación desarrollados con el tiempo.

Esta es también una de las razones por las que comparar velocity entre equipos puede resultar problemático. La velocity en Scrum muestra cuánto puede completar un determinado equipo dentro de su propia referencia histórica, pero no significa automáticamente que ese número pueda utilizarse como una unidad universal de productividad. Cuando escalas diferentes se colocan una junto a otra, el dashboard puede crear una sensación de precisión sin necesariamente producir una comparación justa.

El comportamiento observado en los 204 proyectos refuerza exactamente este punto. Los proyectos con la misma mediana de story points pueden presentar cycle times radicalmente diferentes. Esto significa que los puntos pueden contener información útil dentro de un contexto específico y, al mismo tiempo, perder gran parte de esa utilidad cuando se agregan entre proyectos independientes.

Por qué los story points pueden convertirse en un problema para el PMO

Los story points normalmente surgen como una técnica de estimación Agile utilizada por el equipo, pero en muchas organizaciones terminan convirtiéndose en una de las métricas utilizadas por la gestión. Un PMO puede crear indicadores como total de story points entregados, promedio de puntos por sprint, velocity por equipo, tendencias de productividad, capacidad y comparaciones entre diferentes proyectos.

Todos estos cálculos pueden ser técnicamente correctos y, aun así, generar interpretaciones equivocadas. Si cada equipo creó su propia escala relativa, sumar los story points de varios equipos no transforma automáticamente esos valores en una métrica estandarizada de portafolio. Un equipo que entrega 100 puntos no necesariamente produce el doble de trabajo, valor o resultados que otro que entrega 50.

Los números muestran lo que ocurrió según la referencia de cada equipo, pero por sí solos no son suficientes para explicar por qué un proyecto está entregando más rápido, por qué otro está perdiendo previsibilidad o dónde se está consumiendo la capacidad. Para responder estas preguntas necesitamos analizar otras señales generadas durante la ejecución.

Para mí, es exactamente en este punto donde Project Intelligence necesita ir más allá de la estimación creada al inicio de la actividad. El valor original en story points sigue siendo relevante, pero debe interpretarse junto con aquello que ocurrió después: cuánto tiempo tomaron normalmente actividades similares, cuántas veces quedaron bloqueadas, si atravesaron varios sprints, cuánto retrabajo generaron y cómo se compara su comportamiento con el historial del propio proyecto.

Métricas de entrega para analizar más allá de los story points

Los datos de un proyecto contienen muchas otras señales capaces de explicar cómo está ocurriendo realmente la entrega. El cycle time muestra cuánto tiempo permanece una actividad dentro del ciclo de entrega antes de completarse. El movimiento entre sprints permite observar cuándo una actividad continúa trasladándose de un sprint a otro. Las dependencias revelan cuánto necesita esperar un trabajo por otras actividades, personas o equipos antes de avanzar, mientras que el retrabajo muestra cuándo algo que parecía terminado necesita regresar a ejecución.

Los cambios de responsable también son relevantes, porque una actividad que cambia varias veces de ownership puede comportarse de forma muy diferente a otra ejecutada por la misma persona o equipo de principio a fin. Del mismo modo, un número elevado de transiciones en el workflow puede indicar que una actividad está atravesando más etapas, revisiones o cambios de lo esperado.

Ninguno de estos indicadores necesita sustituir completamente los story points. El valor está precisamente en analizarlos juntos. Una estimación muestra lo que el equipo creía al principio. Los datos de ejecución muestran lo que realmente ocurrió después de que comenzó el trabajo.

Considera dos actividades estimadas en cinco story points. La primera se comporta de forma muy similar a decenas de actividades equivalentes completadas anteriormente por el mismo proyecto. Su cycle time permanece dentro del rango histórico, no existen dependencias relevantes y avanza por el workflow sin grandes interrupciones. La segunda comienza con los mismos cinco puntos, pero queda bloqueada, atraviesa varios sprints, cambia de responsable y acumula retrabajo.

Las dos actividades siguen mostrando cinco story points en Jira. Pero desde el punto de vista de la entrega ya no representan el mismo riesgo.

Los datos históricos del proyecto pueden decir más que la estimación original

Esta es la parte de la gestión de proyectos que más me interesa. En lugar de preguntar únicamente cuántos story points se asignaron a una actividad, prefiero observar cómo se comportaron anteriormente trabajos similares. ¿Cuánto tiempo tomaron normalmente? ¿Cuál fue la variación entre las entregas más rápidas y las más lentas? ¿Las actividades con dependencias presentaron cycle times mayores? ¿Los elementos que atravesaron varios sprints se comportaron de manera diferente? ¿El retrabajo o los cambios de responsable aparecieron antes de que comenzara a aumentar el tiempo de entrega?

El historial del proyecto crea una referencia basada en aquello que realmente ocurrió. No elimina la estimación inicial, pero añade contexto y permite comparar lo que esperábamos con lo que la ejecución está mostrando en realidad. Si actividades similares normalmente se completan dentro de determinado rango de tiempo y una nueva actividad empieza a alejarse rápidamente de ese comportamiento, tenemos una señal mucho más útil que únicamente el número de puntos asignado durante la planificación.

En Saint Jude Project Intelligence, utilizamos los datos del proyecto para comparar las actividades actuales con el comportamiento histórico del propio proyecto y con actividades similares ya completadas. La Inteligencia Artificial ayuda a identificar combinaciones de señales, desviaciones y patrones recurrentes que serían difíciles de detectar observando solamente un campo de Jira, algunas Jira metrics o un reporte aislado de sprint.

El objetivo no es sustituir al gerente de proyectos ni crear una nueva escala de estimación. El objetivo es crear una capa de inteligencia que ayude a PMOs y líderes a comprender si las actividades actuales continúan comportándose de manera consistente con trabajos similares, si la ejecución ha comenzado a salir del patrón histórico y si las premisas utilizadas durante la planificación siguen teniendo sentido frente a los datos disponibles hoy.

¿Qué muestran realmente 204 proyectos en Jira sobre los story points?

Después de analizar 727,282 issues de Jira y comparar story points con medianas de tiempo de entrega en 204 proyectos de software, los datos no respaldan el uso de story points como una métrica universal de entrega de proyectos. Los proyectos con la misma mediana de puntos pueden presentar cycle times radicalmente diferentes, mientras que proyectos que utilizan medianas mayores pueden, en determinados casos, entregar mucho más rápido que proyectos que utilizan valores menores.

Debido a esta variación, el análisis no proporciona una base para afirmaciones como “un story point equivale a X horas” o “un equipo que entrega 100 story points es dos veces más productivo que un equipo que entrega 50”. Ambas afirmaciones dependen de que los story points funcionen como una unidad estandarizada, y eso no es lo que observamos cuando se comparan diferentes proyectos.

Los story points son relativos por definición. Esta característica puede hacerlos útiles dentro de la referencia creada por un equipo, pero también dificulta enormemente utilizarlos como una métrica estandarizada entre equipos, proyectos o estructuras de gobernanza corporativa.

Para mí, la pregunta más útil deja de ser cuántas horas debería tomar una actividad de cinco puntos. La pregunta pasa a ser: considerando el historial de este proyecto y el comportamiento de actividades similares, ¿qué sería razonable esperar de esta actividad ahora?

Es en ese momento cuando una estimación comienza a transformarse en Project Intelligence. El story point sigue siendo una información importante, pero se vuelve mucho más útil cuando se interpreta junto con el comportamiento real de la entrega, los datos históricos y las demás señales producidas por el proyecto durante su ejecución.

¿Quieres entender lo que están mostrando los datos de tu Jira?

Los story points son solamente una de las señales existentes dentro de un proyecto. Saint Jude analiza datos de proyectos para identificar patrones relacionados con tiempo de entrega, riesgos, dependencias, retrabajo, capacidad y previsibilidad, combinando las estimaciones originales con el comportamiento histórico observado durante la ejecución.

Puedes enviar los datos de tu proyecto y recibir un análisis gratuito a través de nuestro Project Health Checker. La idea es utilizar los datos que el proyecto ya produce para entender no solamente lo que debería ocurrir, sino cómo se está comportando realmente la ejecución y qué señales merecen atención antes de convertirse en problemas mayores.

¡Hasta pronto!

Erik Scaranello